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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization sponsored by the 
National Aeronautics and Space Administration/Goddard Space Flight Center 
(NASA/GSFC) and created for the purpose of investigating the effectiveness of 
software engineering technologies when applied to the development of applications 
software. The SEL was created in 1977 and has three primary organizational 
members: 

NASA/GSFC, Systems Development Branch 

The University of Maryland, Computer Sciences Department 

Computer Sciences Corporation, Systems Development Operation 

The goals of the SEL are (1) to understand the software development process in 
the GSFC environment; (2) to measure the effect of various methodologies, tools, 
and models on this process; and (3) to identify and then to apply successful devel- 
opment practices. The activities, findings, and recommendations of the SEL are 
recorded in the Software Engineering Laboratory Series, a continuing series of 
reports that include this document. 

Single copies of this document can be obtained by writing to 

Systems Development Branch 
Code 552 

Goddard Space Flight Center 
Greenbelt, Maryland 20771 
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SUMMARY OF THE SECOND NASA ADA USERS’ SYMPOSIUM 


On November 30, 1989, approximately 370 attendees gathered in Building 8 at the 
National Aeronautics and Space Administration (NASA)/Goddard Space Flight 
Center (GSFC) for the Second NASA Ada Users’ Symposium. The symposium 
was created as a forum for NASA centers and contractors to exchange their ideas, 
plans, and experiences in using the Ada language or related methods and tools. It 
is sponsored by NASA/GSFC and hosted by the Goddard Ada Users’ Group. 
Among the audience were representatives from 3 universities, 17 government agen- 
cies, 7 NASA centers, and 75 private corporations and institutions. Eleven papers 
were presented in three sessions: 

• NASA-wide Activities 

• Center and Project Activities 

• Space Station Activities 
SESSION 1 - NASA-WIDE ACTIVITIES 

Ed Seidewitz of GSFC opened the symposium, welcomed attendees, and intro- 
duced the first speaker. The lead-off presentation, “Ada in NASA: Policy and 
Directions,” was given by Frank McGarry, also of GSFC. McGarry described the 
four-step process of formulating NASA policies for Ada: 

1. Assess current capabilities/needs/directions 

2. Conduct an open review of findings/recommendations 

3. Formulate the positions/recommendations of each NASA center/office 

4. Develop an action plan for NASA 

McGarry indicated that the first three steps have been completed. The response 
from NASA contractors has been very supportive of the recommendation that 
NASA adopt Ada, but issues, questions, and considerations were identified. The 
response from NASA centers has been mixed, with four centers supporting an Ada 
mandate, five supporting Ada but without mandate, four uncertain, and three op- 
posed. The primary concerns expressed by NASA are the cost and maturity of 
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Ada technology. McGarry concluded by stating that completion of the NASA ac- 
tion plan has been understandably delayed by a change in NASA administration, 
but that some centers may move ahead and adopt Ada on a center-wide basis. 

The second speaker, Robert Nelson of the Space Station Freedom Program Office, 
provided an update on the current status of the Space Station Freedom program 
and discussed where Ada fits in (“Ada and the Space Station”). Most systems are 
currently reviewing software requirements. A major impact on the program has 
been the reduction in the power budget for the in-orbit portion, which has caused 
reevaluation of the planned software and computer capabilities. 

Nelson discussed the program-level risk management plan and noted that Ada was 
not identified as one of the top 10 risks, although it does appear on the list. An 
object-oriented architecture is evolving and a task team met recently to address 
some overall architectural issues. The current estimate of the total size of space 
station software is 10.5 million source lines of code (SLOC), mostly Ada. Nelson 
pointed to the number of interfaces and to the phased on-orbit assembly as repre- 
senting significant software challenges for the Space Station Freedom program. 

The final speaker in the first session, Frank Barnes of Lockheed, presented “Soft- 
ware Support Environment (SSE): Program Status.” The intent of the SSE is to 
support the management of Space Station software development by NASA and its 
contractors. Barnes described the dissatisfaction of users with the current release 
of SSE. The overhead that results from managing any process, along with the 
immaturity of the current SSE release, account for much of this dissatisfaction. 
Although the final system is scheduled for release in mid-1993, much of its capa- 
bilities are needed now. Barnes described the current user interface as “user- 
surly,” while noting that improvements in this area are planned for August 1990. 
The current release is also manually intensive, a problem that should be addressed 
by January 1991. Barnes summarized the SSE’s major challenges as achieving a 
consensus among its many users, supporting multiple host systems, and providing 
capabilities that match the Space Station development schedule. 
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SESSION 2 - CENTER AND PROJECT ACTIVITIES 

Ed Seidewitz of NASA/GSFC presented “Ada in the SEL: Experiences with Op- 
erational Ada Projects.” The Software Engineering Laboratory (SEL) develops 
about 15 percent of its software in Ada for systems ranging in size from 68K to 
170K SLOC. The SEL is currently in its fourth generation of Ada projects and 
some trends have been noted. The use of generic packages and user-defined types 
has increased, while the average size of packages and the use of tasks has de- 
creased. Productivity, in statements per day, has been comparable to or lower than 
that typical of FORTRAN projects. However, a strong trend in the latest Ada 
projects toward increased reuse, attributable to Ada and Object-Oriented Design 
(OOD), has had the effect of greatly increasing effective productivity. 

Seidewitz also described the results of a study porting a system from DEC VAX/ 
VMS Ada to Alsys IBM/MVS Ada. The study indicates that even without designing 
for portability, the conversion of Ada code required only half as much time as 
would be expected for an equivalent FORTRAN system. Seidewitz concluded by 
identifying plans for future Ada work, which include a real-time embedded system; 
a large generalized flight dynamics support system; and studies of performance, 
reliability, and maintainability. 

Discussing activities on the Second TDRSS Ground Terminal project (STGT), 
Sara Cohen of General Electric presented “The Application of CASE Technology 
and Structured Analysis to a Real-Time Ada Project.” At the start of the project, 
all engineers and managers were trained in Ada. In addition, the effort was led by 
a core team experienced in Ada, large projects, and ground station development. 
These factors, along with the use of CASE technology, have contributed to the 
success of the project to date. Diagrams have proved an excellent means of com- 
munication among the team and with the customer. A data dictionary helped 
ensure consistent naming among team members. Not only did the CASE tool 
make design updates easier, it performed better consistency checking than would 
have been possible otherwise. 

Cohen concluded by summarizing the benefits of using the CASE tool. The analy- 
sis and design products developed using the CASE tool made up about 80 percent 
of the Software Requirements Specification, which resulted in higher productivity 
than traditionally estimated. During preliminary design, the CASE model evolved 
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into the software design. The model also served as the basis for the system per- 
formance study and facilitated production of the software test plans. 

Tom Fouser from the Jet Propulsion Laboratory (JPL) presented “Ada at JPL: 
Experiences and Directions.” JPL develops systems for internal research and de- 
velopment and for the Department of Defense, as well 'as for NASA missions. 
Currently JPL is working on a number of Ada projects. When used by Ada experts 
for rapid prototyping, high productivity (18 statements per day) has been achieved. 
Several other projects have seen the early design phases take longer, but anticipate 
that later phases will be shortened. For training, JPL has used a combination of 
in-house courses presented over a period of weeks and intensive courses brought in 
from outside. In addition to development using DEC’S VAX/VMS environment, 
there is an increased use of the Rational development environment. Also, a study 
performed for flight software found some deficiencies in performance and schedul- 
ing, but these have been overcome by using a non-Ada real-time kernel in conjunc- 
tion with an Ada application. 

Fouser observed several common features among the variety of projects using Ada. 
The general approach has been to staff a project with a mix of outside Ada con- 
sultants and in-house management and engineers. In this way the base of trained 
and experienced JPL engineers and managers is growing. Each project generally 
encounters some problems, but finds a satisfactory work-around. More and more 
projects are starting to use Ada; even those initially skeptical are beginning to 
consider it a viable option. 

The last speaker of the morning sessions, Walton Harless of TRW, presented “Ada 
and the OMV Project.” The Orbital Maneuvering Vehicle (OMV) is a remotely 
controlled vehicle that will be used to assist in the launch and retrieval of satellites 
beyond the shuttle s range. The flight segment contains about 14K to 20K SLOC, 
almost exclusively in Ada. The ground system uses a mix of languages, including 
Ada. Although initially proposed in FORTRAN and C, by the time of contract 
award the motivation to use Ada had increased; hence, the flight segment and 
ground system command and control software are being developed in Ada. 

Harless characterized training for the project as including formal on-site training 
for managers, designers, and developers. After an extensive trade study, the 
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project selected the TLX) VAX-to-1750A cross-development system. Prototyping 
on the TLD system indicated that some Ada features (e.g., tasking, variant re- 
cords, and dynamic storage) were inappropriate for the flight segment. Harless 
described the porting of Ada software between VAX, Alliant, Sun, and PCs as 
relatively painless. However, when attempting to interface between dissimilar sys- 
tems, he noted that tighter control must be used in specifying data representation. 
Harless concluded by stressing the importance of early prototyping with the target 
compiler in order to understand its strengths and weaknesses and thus guide the 
design. 

SESSION 3 - SPACE STATION ACTIVITIES 

Kathy Rogers of MITRE presented “Lessons Learned: Prototyping with Ada for 
the Space Station Freedom Program.” The goal of the prototyping effort was to 
examine human interface factors and gain experience with Ada and OOD. Al- 
though OOD seemed to fit the problem and Ada design well, extra effort was 
required to translate from functional requirements to an OOD and again from the 
OOD to the data flow diagrams that the reviewers felt comfortable with. During 
coding, the project found that Ada’s ability to separate specification from imple- 
mentation facilitated independent development. The parallel evolution of the 
project’s external interfaces, however, caused significant reworking of the simula- 
tion code that was used for testing, a consideration not included in the project 
plans. The project found that DEC’S documentation and technical support were 
weak in interfacing with other languages and operating system services, an area 
where an expert consultant would have helped. Rogers concluded the presentation 
by stating that much was learned on the project, and overall Ada was found to be a 
good tool. 

Next, Cora Carmody of Planning Research Corporation presented “Software Sup- 
port Environment Architecture and Design Overview.” Carmody began by reiterat- 
ing the point made earlier by Barnes that the Space Station SSE must satisfy the 
often conflicting needs of creating a long-term, lower cost life-cycle and supporting 
immediate user needs in a variety of environments. The current design, based on 
stable standard interfaces, represents this balance. The architecture utilizes an 
object specification-driven definition of life-cycle products and processes. 
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The architecture is divided into four layers: Common User Interface Services, 
Environment Applications, Process/Object Management, and Platform. The Com- 
mon User Interface Services provides both a graphical and a textual command 
interface. The Environment Applications layer provides the real tools from the 
user’s viewpoint. The Process/Object Management layer provides access control, 
and the Platform layer implements a virtual machine that insulates the higher lev- 
els from the host system implementation. For performance reasons, the upper 
layers may bypass intermediate layers and use the Platform layer directly. 

Carmody summarized the benefits of the object-oriented approach as reduction of 
life-cycle costs (by encouraging reuse and reducing maintenance costs) and en- 
hanced system integrity and security. 

Robert LaBaugh from Martin Marietta spoke next on their experiences developing 
Ada software for the “Flight Telerobotic Servicer.” The Flight Telerobotic Ser- 
vicer (FTS) is a sophisticated robot that will be able to perform remote servicing 
tasks controlled from the Space Station. The current estimate is that 224K SLOC 
will be developed for the FTS, entirely in Ada. The flight software represents the 
most significant category of code and will be implemented on a distributed system 
of 22 Intel 80386 microprocessors that control the motion of the robot in real time. 
The project is using the DDC-I Ada Compiler for 80386 protected mode, which 
allows full use of the 32-bit architecture. The flight software will run without any 
operating system, using the Ada run-time system to support interrupt handling, 
low-level I/O, tasking, and memory management. 

LaBaugh stated that to date, their prototyping efforts have not uncovered any defi- 
ciencies in the Ada run-time system that preclude its use for real-time robotic 
control. LaBaugh closed by presenting the results of performance benchmarks on 
various control algorithms and matrix operations. 

The final speaker of the symposium, Pete Gacuk of SPAR Aerospace, presented 
“Lessons Learned in Prototyping the Space Station Remote Manipulator System 
Control Algorithms in Ada.” The Space Station Remote Manipulator System will 
be an advanced descendant of the space shuttle robot arm. The multiple goals of 
the prototyping effort examined issues related to life-cycle, methodologies, Ada 
development, technical communications, Ada performance, and configuration 
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management. Rather than use an informal or shortened life-cycle, the prototype 
effort used a full life-cycle with formal reviews and participation by product assur- 
ance and configuration management personnel in order to better represent the 
production environment and broaden the organization’s experience. 

Gacuk stated that the project adopted a hybrid methodology (a combination of 
NASA/GSFC GOOD and Booch OOD), as this provided a transition from struc- 
tured analysis to OOD. They found that typical Ada and OOD diagrams did not 
provide a good basis for communications between software developers and hard- 
ware engineers or testers, but that multiple notations (data flows, Booch-grams, 
withing diagrams, tasking diagrams, timing diagrams, state diagrams, and excep- 
tion diagrams) were needed to represent different aspects and to provide interdisci- 
plinary communications. The initial performance of the prototype was 
disappointing; however, after profiling and some recoding, the desired perform- 
ance was achieved. 

Gacuk concluded by presenting some “lessons learned about lessons learned.” 
First, good notes are needed throughout the process in order to document lessons 
learned. Second, the conclusions reached are likely to change during the process 
as you learn more. Third, lessons learned should be “stale dated,” as they often 
lose their value over time. Finally, without champions who continue to present and 
push lessons learned, the lessons often go unlearned. 
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SESSION 1 - NASA WIDE ACTIVITIES 
Session Leader: E. Seidewitz, NASA/GSFC 


Ada in NASA: Policy and Directions 
F.E. McGarry 

Ada and the Space Station 
R. Nelson 

Software Support Environment (SSE): Program Status 
F. Barnes and D. Badal 
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“ADA IN NASA: POLICY AND DIRECTIONS” 
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...IN GENERAL SUPPORTS... 



NASA FORUM/SYMPOSIUM 
INDUSTRY PERSPECTIVE ® 


LU 


O 

DC 

> 


CD 

< 

> 

Q 

Z 

< 

CO 


< 

o 


LU 

dc 

3 

\— 

O 

3 

GC 

I- 

CO 

CO 

Q 

CC 

< 

Q 


CO 

To 

■o 

< 


m ^ 

ZclO 
O ^ i= 


OO 

Oco 

si 

CO CO 
3UJ 

°2 

o o 


CO _ 

of 

°-3 

Oco 

y= o 

os= 

LU 2 
CL >- 
CO CO 


z 

o 


o 

o 

CO 
Q 
dc 
< 
Q 
Z 
< 
I — 
CO 

CL 

O 

LU 

> 

LU 

Q 

To 

TJ 

< 

LU 

Q 


I— 

Z 

LU 

2 

LU 

CO 

CC 

O 

Q 

z 

LU 


LU 


LU 

CO 

< 

CO 


LU 

z 

O 

DC 

> 


< 

lu w 
> < 
Ox 

O co 


< Z H 
2 LU 


5<M 
CC LU 
CO 
CO 3 


LU 

O 

O 


LU 


LU 

o 

O 


c^- 

c 

CO 

LU 

o 

CC 

O 


CO 

< 


LU 


oQ _ 

5s 2 


LU 

> 

1— 

O 

LU 

CL 


< 

DC 

tr 

DC 

o 


CO LL 
DC 


LU 

CL 

LU 

CO 

CO 


DC 

O 

CL 

CL 

3 

CO 

O 

z 

o 

DC 


o 

i — 
QC 
< 

b CC 
< h- 
O CO 

LU Q 
2Z 


Q 
LU 
CO 

< t— 

CD CO 


O 

O 

LU 

CC 


CO 

LU 

O 

O 


£ 

DC 


Q 

LU 

LU 


LU 

(D 


O 

O 


F. McGarry 
NASA/GSFC 
10 of 20 


• BOEING • STRONG OVERALL SUPPORT 

• NO INCENTIVES SHOULD BE NECESSARY 

• IMPACT ON BOEING WOULD BE POSITIVE 
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IMPLEMENTATION SHOULD BE ACCELERATED 
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• 0S0 (CARRO) • PROPOSED TRANSITION TO Ada TOO LONG 

• NEED COST STUDY AND COST CONTROL 
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• LEWIS (SCHUBERT) • CONCERN FOR COSTS 

• “MANDATE” WILL RECEIVE RESISTANCE 



PREPARE “OFFICIAL” CENTER/OFFICE RESPONSES © 
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(MANDATE Ada + ) 

• MUST SUPPORT STRONG CENTRAL OFFICE (HQ) 
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STENNIS • FULL AGREEMENT AND SUPPORT 

• EXTEND SCOPE OF Ada USE BEYOND “MISSION SOFTWARE 
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NO INDICATION OF SUPPORT OR AGREEMENT 
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• B/D/H/L/X • NOT APPLICABLE 
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• MATURITY 

• INERTIA 



DEVELOP NASA ACTION PLAN 
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Ada IN NASA - POLICY AND DIRECTIONS 
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“ADA AND THE SPACE STATION” 


R. Nelson, Space Station Freedom Program Office 
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Program Milestones 

Program Requirements Review 
Preliminary Design Review 
Critical Design Review 
SSF Training Facility ORD 
SSF Control Center ORD 
Design Certification Review 
Operations Readiness Review (ORF 
SSF Processing Facility ORD 
First Right Hardware Delivery (FFHC 
Payload Training Complex ORD 
First Right Readiness Review (FFRF 
First Element Launch (FEL) 

FTS Availability 

F>rogram Operation Integration Cent 
Canadian Mobile Servicing Center 
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INTERFACE REQUIREMENT DOCUMENTS (IRDs) 


BASELINE REQUIREMENT CHARACTERIZATION 
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Software criticality assessment and associated verification planning 


SOFTWARE REQUIREMENTS REVIEW TOPICS 
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SRR SCHEDULE 
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REQUIREMENTS FOR SSMB SOFTWARE 
ARCHITECTURE DEVELOPMENT 



Structure - How is the 
data organized? Hew 
does a building Block 
access it? 



SSMB GLOBAL DATA STRUCTURE ORGANIZATION 
AND ACCESS CRITICAL TO CSCI DEVELOPMENT 
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POTENTIAL 

SYSTEM / SYSTEM SOFTWARE INTERFACES 



(H - WP/WP SOFTWARE INTERFACE 
X - SYSTEM /SYSTEM SOFTWARE INTERFACE 
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Software Risk Management 
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RISK MANAGEMENT = RISK ASSESSMENT* CONTROL + MONITORING 






TOP 10 SSF SOFTWARE RISK ITEMS 
IDENTIFIED BY TRW 
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R033 Operating System Selection - real time shortfall 
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SFP SOFTWARE SIZE ESTIMATE 
BY SOFTWARE TYPE 
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POST SCRUB 

INSTITUTIONAL GROUND FACILITY CSCIs NOT CURRENTLY IDENTIFIED lav 006 1 1/8/89 




Should there be a standard for the conversion of Ada source 
lines of code to computer memory usage? 
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“SOFTWARE SUPPORT ENVIRONMENT (SSE) 
PROGRAM STATUS” 


F. Barnes, Lockheed 
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SSE PROJECT OVERVIEW 
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SSE SYSTEM PROJECT 


UJ 


<0 


< 

O 

z 

UJ 

o 

< 


UJ 

CO 

O 

CL 

CC 


o 

CC 


UJ 


UJ 

s 

Ul 

o 

< 


UJ 

o 

o 

o 


o 

< 

o 

CC 

QL 

0. 

< 


UJ 

m 

(D 


fc 

Q 

0 

| 

1 

CC 

UJ 


o 

o 


(0 

CC 

UJ 


o 

o 

& 

o 

CC 

o 


UJ 

CC 

I 

Q 

CC 

< 


(/) 

§ 

CO 

£ 

Ul 

o 


CC 

o 

LJ- 

GC 

UJ 

Q. 



F. Barnes 
Lockheed 
10 of 28 


SCHEDULE: 
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SURVEY OF CANDIDATES; 

As of June 1989, over 260 Ada compilers have been validated. The best form of Informa- 
tion to determine the vendor and type of computers that these compilers were validated on 
comes from the "Ada Information Clearing House" newsletter. Another source is the "Lan- 
guage Control Facility Ada-Jovial" newsletter. 
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Hard Ada Real Time Test Suite (HARTSTONE) 

SSE Ada Test Suite (SATSTONE) - to be generated 
ln__Circuit_Emulator (ICE) and Software Analyst Workstation (SAW) 
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formed an evaluation on the 68K. 
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This figure shows the hardware configuration of the 80386 ’’bare” target test facility. It 
includes a PS2/80-1 1 1 to serve as the target. Also included Is a PS2/60 and IBM AT to be 
used for the running of performance measurement systems. 
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operating system becomes available, the compilers will be re-run with the OS, thus provid- 
ing performance data that can be normalized to the ’’bare” configuration. The following 
two charts show each configuration. 





Terminal 
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The following performance measurement benchmark systems will be used during the 
cross-compiler evaluation period: 

1 . Ada Compiler Evaluation Capability (ACEC) 
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OBJECT DE-ALLOCATION AT 
INTERRUPT RESPONSE TIME 


This chart reflects the tasks associated with the cross-compiler evaluation. For the first 
half of 1989, the following tasks were planned and have been completed. 

1 . Run all the benchmark test suites on SSEDF equipment. 
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VERDIX SCHEDULED TO BE AT SSE ON 6 NOV WITH COMPILERS 
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SESSION 2 - CENTER AND PROJECT ACTIVITIES 


Session Leader: M. Stark, NASA/GSFC 


Ada in the SEL: Experiences with Operational Ada Projects 
E. Seidewitz and M. Stark 

The Application of CASE Technology and Structured Analysis 
to a Real-Time Ada Project 

S. Cohen 

Ada at JPL: Experiences and Directions 

T. Fouser 

Ada and the OMV Project 
W. Harless 






“ADA IN THE SEL: EXPERIENCES WITH OPERATIONAL ADA 

PROJECTS” 

E. Seidewitz, NASA/GSFC 
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Ada IN THE SOFTWARE ENGINEERING 
LABORATORY: EXPERIENCES WITH 
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SAMPLE OF 9 FORTRAN PROJECTS 
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Ada PROJECTS IN FLIGHT DYNAMICS DIVISION 
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USE OF Ada FEATURES 
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• USE OF Ada FEATURES CHANGES APPRECIATELY 
WITH EXPERIENCE 

• NOT ALL FEATURE APPROPRIATE FOR APPLICATION 
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EUVETELS SPECS WRITTEN AS A DERIVATION OF UARSTELS 
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• Ada HELPS CUT INTERFACE ERRORS 



PORTABILITY STUDY 
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- EFFORT: ~250 STAFF YEARS 

- SCHEDULE: 1989-1996 
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The Application of CASE Technology and Structured 
Analysis to a Real-Time Ada Project 

Sara Cohen 

General Electric/STGT 
P.O. Box 8048 - Bldg. 25, Rm. 22S05 
Philadelphia, PA 19101 

Introduction 

System requirements analysis frequently poses a challenge to a project development team. 
Traditional life-cycle methods used to analyze system and software requirements often re- 
sult in lengthy text without graphical representation. This documentation is difficult to 
modify and check for consistency. The use of Structured Analysis (SA) has alleviated many 
of the disadvantages associated with traditional system and software requirements analysis 
methods. System and software requirements analysis using SA techniques is more com- 
plete, easily understood, precise and comprehensive. Benefits of SA are apparent in the 
System Requirements Analysis/System Design and Software Requirements Analysis phases. 
The experiences of the Second Tracking and Data Relay Satellite System (TDRSS) Ground 
Terminal (STGT) project to date have shown that the benefits of SA can be realized as 
far into the project life-cycle as the Detailed Design Phase. This paper will discuss the 
requirements analysis methodology exercised on the STGT project, as well as its benefits 
into the Detailed Design Phase. 

Background 

The Second Tracking and Data Relay Satellite System (TDRSS) Ground Terminal (STGT) 
is a real-time project which will contain over 450,000 lines of custom executable Ada code 
and approximately 2,000,000 lines of Commercial Off The Shelf (COTS) software. It pro- 
vides the National Aeronautics and Space Administration (NASA) with tracking, telemetry 
and command of the TDRS, and high quality data communication service to the user com- 
munity. The STGT mission requirements include implementing NASA's allocation of sys- 
tem resources, maintaining high quality forward and return links, providing system perform- 
ance and status data to the Network Control Center (NCC). and providing efficient ground 
station maintenance to meet the high quality and availability requirements of the STGT 
users. STGT will provide high operational availability to the user community with less than 
fifty-five minutes down time per year (no more than 10 seconds at a time). A distributed 
architecture and multiple Computer Software Configuration Items (CSCIs) ate employed 
to facilitate development, flexibility, maintenance, documentation, and control of the soft- 
ware necessary to operate and maintain the STGT. 
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Upon completing successful project reviews - a System/Subsystem Requirements Review 
in March 1989 and a Preliminary Design Review in August 1989, STGT is currently in the 
Detailed Design Phase. Software developers are identifying units according to DoD- 
STD-2167 and producing Ada package specifications and Ada Program Design Language 
(PDL). Subsystem Critical Design Reviews are scheduled to begin in January 1990 with 
the infrastructure CSCIs and continue through April 1990 for the remainding CSCIs. A 
system Critical Design Review is scheduled for June 1990. The Coding, Unit and CSC Test- 
ing Phase will begin in January 1990 and continue through October 1990. 

STGT’s software development team currently numbers fifty-five. Eleven STGT developers 
participated in an intensive Ada training program for one year prior to the start of full- 
scale STGT development. During this training, they completed at least one Ada project 
in technology directly applicable to STGT. In addition, they are experienced in the area 
of large-scale ground station projects. These software developers were assigned to lead 
the development of the CSCIs. All STGT software developers were required to complete 
an Ada individualized training program which required at least eighty hours. This self- 
paced program consisted of a multi-media curriculum including computer-based and text- 
based training, lectures, and hands-on application. Many STGT software managers either 
had previous Ada experience or completed the Ada training program. STGT software devel- 
opment management recognized the importance of management, as well as individual con- 
tributors, receiving software engineering and Ada design training specifically for real-time 
systems. Additionally, STGT software managers attended Ada management training 
classes. 

Traditional Requirements Analysis vs. Structured Analysis 

The early '70s introduced project management methods based upon models of the software 
development life-cycle. This called for documents to be produced at specific points within 
the life-cycle according to prescribed forms and standards or document content guidelines. 
These methods stressed the capture of documentation during the development process, but 
did not adequately provide for the continued usefulness of the documents. The specifica- 
tions were often incomplete, inconsistent, incorrect and not always updated to reflect 
changes made to the system. Lack of formality, resulting in inconsistency, and lack of main- 
tainablity have been identified as the problems which have limited the effectiveness of the 
life-cycle based methods. 

It was obvious that more formal methods than those mentioned above were nece^arv it 
greater productivity was to be achieved. In the late ‘70s and early ‘80s. more formal methods 
were introduced, most notably structured analysis and structured design. These methods 
shifted the emphasis from later phases of the life-cycle to earlier ones. More time should be 
spent in the Requirements Analysis Phase, as well as the Preliminary and Detailed Design 
Phases. Less time and money would be spent in the Coding, Testing and Maintenance 
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Phases, since errors would be detected at the earliest possible time. Implementation would 
be easier and the resulting software would be of higher quality. 

Tom DeMarco is credited with popularizing structured analysis. He explained that through 
the use of data flow diagrams and descriptions of data (i.e. data dictionary, process specifi- 
cations and decision tables), one could build a systematic description of a system’s logical 
(functional) and physical (implementation) aspects. Management could control the activi- 
ties by conducting walkthroughs where data flow diagrams, the data dictionary, process 
specifications and decision tables could be manually validated. The data flow diagrams and 
the data dictionary became system document deliverables. According to DeMarco, if the 
person performing the structured analysis is doing so correctly, the structured specification 
would have the following qualities (l): 

1. It would be graphic. The data flow diagrams would present a meaningful, easily 
understood, picture of what is being specified. 

2. It would be partitioned. The processes depicted on the data flow diagrams would 
represent the basic elements of the system. 

3. It would be rigorous. The data dictionary would provide a rigorous document of the 
interfaces and the process specification would be rigorous as well. 

4. It would be maintainable. Redundancy would be minimized and used in a controlled 
manner. 

5. It would be iterative. The specification would be shared with the user and modified 
according to his/her needs until correct. 

6. It would be logical, not physical. By eliminating elements that depend upon things 
such as hardware and vendor, one need not concern oneself with changes in physical 
thinking. 

7. It would be precise, concise and highly readable. 

Fulfilling these qualities, the structured specification would then exemplify the popular 
saying “a picture is worth a thousand words”. A system specification properly decomposed 
into data flow diagrams would be more easily communicated than the traditional tonnage of 
requirements documentation. 

With the methodology in place, there was a need for tools in order to provide automation. 
Without these tools, it would be less practical or economical to use formal system de\<l<>p- 
ment methods. In the mid ’80s, with the spread of desktop computers, a technologv known 
as Computer Aided Software Engineering (CASE) was introduced. It was comprised ul 
environments and tools which would allow the user to model a system from its initial user 
requirements through design and implementation. Tests could be applied in order to check 
for consistency, completeness and conformance to standards. In other words, these tools 
would assist the user in expressing his/her structured analysis and design models. They 
would not create the models for the user. 
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Benefits of Structured Analysis During the Requirements Analysis 
Phase 

Given the complexity of the STGT, analyzing the system requirements was a challenge. The 
NASA Requirements Specification for STGT was analyzed using Structured Analysis (SA) 
techniques. Cadre Technologies Inc.’s TeamvwrL/SA® was selected as the CASE tool to 
support the structured requirements analysis process. This selection was due to GE Military 
& Data Systems. Operations’ (M&DSO) business association with Cadre Technologies Inc. 
Cadre Technologies Inc. is a large, stable company willing to accomodate M&DSO’s needs. 
Their products met M&DSO’s key requirements, among which was the capability to support 
multi-users and multiple platforms. 

The system requirements analysis was rigorous, easily understood, precise and comprehen- 
sive. The system model’s data dictionary served as a basis for hardware/software interface 
specifications. The system model itself provided a sound foundation upon which software 
requirements analysis could be performed. 

Applying the same techniques as were applied in the systems requirements analysis phase, 
each CSC1 developed a levelled model in which the requirements specific to the CSCI were 
captured. The models consisted of multiple levels of data flow diagrams reflecting corre- 
sponding levels of functional detail. Individual requirements were enumerated in the pro- 
cess specifications. Intra-CSCI, as well as, inter-CSCI data flows were defined in the data 
dictionaries. The use of Teamwor£/SA®’s checking capability ensured that the data flow 
diagrams were syntactically correct and that they balanced with their child data flow dia- 
grams and process specifications. The software requirements specifications produced were 
precise, concise and highly readable. 

Teamww*/SA® did, however, have one limitation. Since the number of users accessing 
a particular data base simultaneously was limited to eight, it was decided that each CSCI 
would develop its own model. All of the CSCls could not be accomodated in one data base. 
This meant that each CSCI would have its own data base. All consistency checking between 
CSCls was performed manually. A manual procedure was used where data dictionaries 
were merged and definitions were checked for consistency. This procedure, unfortunately, 
was not 100% foolproof. An automated procedure would have been more efficient. 

The software requirements models and data dictionaries provided for 80 % of the SRSs' 
content. Interleaf Publishing Software was used to produce the SRS documents. The produc- 
tion of the SRSs was enhanced due to the software utilities, commercial and in-house, 
available to incorporate the Teamwork® models into Interleaf documents. 


Teamwwtf/SA® is a registered trademark of Cadre Technologies. Inc. 
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Software developers produced the SRSs using these tools, leaving the Technical Publications 
group the task of merely applying cosmetic changes.These SRSs were delivered to the cus- 
tomer at the System/Subsystem Requirements Review. 

Based upon GE’s initial Ada project experiences and modern software engineering princi- 
ples, it was projected that STGT would spend 10-15% of its software hours in the Require- 
ments Analysis Phase. In fact, over 9% of STGT’s budgeted software hours were spent 
performing requirements analysis. 

The development of the requirements models produced some unexpected benefits. The 
graphics depicted in these specifications proved to be an excellent means of communication 
with NASA during the requirements analysis walkthroughs. They were equally helpful to 
convey ideas or work out issues with colleagues. In addition, the data flow diagram models 
served as good training medium as new STGT personnel familiarized themselves with the 
system. 

Benefits of Structured Analysis During the Preliminary Design Phase 

The basic goals of the Preliminary Design Phase were to develop a top-level design for 
each CSCI reflecting the requirements specified in the SRSs and to develop a lower-level 
design for Computer Software Components (CSCs) which were identified as critical ele- 
ments of the design. Critical elements were defined as those required at an early date for 
the development of other CSCs, those having a long development period and/or those hav ing 
performance requirements that would be especially critical. 

Employing an object-oriented design approach tailored to the needs of STGT, the first step 
of preliminary design was to identify objects, physical and abstract, in the system. The 
objects would contain state data and provide operations on that data. Object-oriented CSCs 
encapsulated objects within a CSCI. Object-oriented design, however, had its limitations. 
Concurrency would not be addressed until object implementation. Overall system concur- 
rency would not be addressed and control was not obvious. In order to address these limita- 
tions, process-oriented CSCs were identified. The process-oriented CSCs encompassed 
major portions of the processing to be employed by the CSCI. 

The identification of concurrent processes within STGT was based upon an “Edges-ln” 
approach, where the processes necessary to control the external devices were identified 
first. The rules used to identify concurrent processes were: 

1. External devices: These processes were designed as simple device 
drivers to run at the speed of the device. 

2. Functional cohesion: Closely related functions were combined into a 
single process. 

3. Time-critical functions: High-priority processes were identified due 
to their time criticality. 
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4. Periodic functions: Separate processes were identified for periodic 
functions to be activated at the proper time intervals. 

5. Computational requirements: Low-priority processes were identified 
for functions which were not time critical and often computationally 
intensive. 

6. Temporal cohesion: Functions performed during same time period or 
immediately following certain events were combined into a single pro- 
cess. 

7. Data base functions: Functions which needed access to a shared data 
base were aggregated into a single process with mutual exclusion as 
the access mechanism. 

With the design approach in place, the software requirements model was an excellent start- 
ing point for the “carving process”. Transforms and their decompositions were examined 
with the rules described above in mind. Process-oriented CSCs were identified as a result 
of this technique. Many of the data stores in the model were initial object candidates. Figure 
1 illustrates the results of the “carving” process. The data flow diagram depicted is a high 
level data flow diagram. This data flow diagram, in addition to its child data flow diagrams 
were used to carve out the Ground Equipment object-oriented CSC, Perform Operator Initi- 
ated Testing process-oriented CSC, Maintain Service Status Data process-oriented CSC. 
Perform Failover and Automatic Fault Isolation process-oriented CSC, Monitor Ground 
Equipment process-oriented CSC and Control Ground Equipment process-oriented CSC. 

During the Preliminary Design Phase, two activities, other than software design, benefited 
by the results of the Requirements Analysis Phase. A system performance study was con- 
ducted and used the software requirements models to define transactions. In addition, the 
software test group found that production of the software test plans was facilitated by the 
clarity of the requirements. 

Benefits of Structured Analysis During the Detailed Design Phase 

Entering the Detailed Design Phase, the initial goals were to refine the CSCs, identify Ada 
tasks and VMS processes and finally to select units, generate Ada package specifications 
and Ada PDL. The role of the software requirements model was smaller than in the previous 
phases. The models represented a solid understanding of the physical requirements. In a 
number of areas, however, software developers felt the need to address implementation 
issues, prior to unit selection. This was satisfied by further decomposing the Miltwao n- 
quirements models. Again, the “carving" technique was employed. Data Morev a- well 
as transforms or groups of transforms were prime candidates for units. 

Lessons Learned 

To date, the STGT team. GE and NASA, feels that the requirements analysis performed 
on this program was successful. There have been, however, a couple of lessons learned 
from this experience. 
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• The use of modern software engineering principles on a program 
whose schedule has been set with the traditional emphasis of effort 
in the later project phases (e.g. Code and Unit Test Phase) can cause 
a conflict. Typically, in this situation, not enough time is allocated to 
the Requirements Analysis Phase causing requirements analysis to be 
continued into the Preliminary Design Phase. 

• It is not easy to separate implementation from requirements issues 
when developing a requirements analysis model. However, when de- 
sign concepts are incorporated into the requirements model, the SRSs 
have to be repeatedly updated during the course of the project to reflect 
changes in the design! Additionally, as derived requirements are incor- 
porated into the models, software developers spend much of their time 
balancing the models. This interrupts precious time which could be 
spent on design activities. 

Conclusion 

“Is SA suitable for an Ada project to be designed using an object-oriented approach?” is 
a question often asked. The experiences of STGT have shown that using SA for a large-scale 
Ada project resulted in a rigourous, precise and comprehensive requirements analysis. The 
software requirements models were useful in many areas - directly and indirectly related 
to the software development process. It is our feeling that the use of SA played a key role 
in the success of STGT’s requirements analysis. The effect of using SA was so great that 
its benefits were realized into the Detailed Design Phase. 
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Developers Ada certified 

Significant software engineering, Ada design, and Ada 
management training 

Managers trained in software engineering and Ada - major 
contributor to success 
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A PICTURE IS WORTH A THOUSAND WORDS 
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Unique name for each data item 
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Teamwor*/SA® is a registered trademark of Cadre Technologies, Inc. 
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Chart 12 



Chart 14 


o a 

£ i 


'O C8 
C 'O 
c« 

§38 g 

© S 
2 H 

.3 -i- 

0 68 

5 <u 

H PS 


s ® 

.2 _g 

cj x3 
*pS cl> 

a j* 

< § 


© 7j 

£* ^ 

Pu o 

U 


H ^ 




S. Cohen 
GE/STGT 
24 of 24 


Documentation Burden!! 





“ADA AT JPL: EXPERIENCES AND DIRECTIONS” 
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Ada compile time slow (up to 5x FORTRAN); run time okay 
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used DEC Windows ( Ada binding not mature ) 



Real-Time Weather Processor ( Cont’d ): 
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Ground Communications Facility (Cont’d): 
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Project-specific training also 
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have possibilities ( functional and performance ) 
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in C or assembly language 
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“ADA AND THE OMV PROJECT” 


W. Harless, TRW 






OMV Overview and Ada Lessons Being Learned 
Walton Harless 

Abstract . The Orbital Maneuvering Vehicle (OMV) project is involved 
in the development of an unmanned, remote control, reusable 
utilitarian space vehicle and the associated support subsystems. 
The vehicle is to be deployed and recaptured by the Space Shuttle. 
All functional requirements are derived from a set of Design 
Reference Missions which describe a composite set of overall 
capabilities. The development effort is managed by the Marshall 
Space Flight Center with a launch date scheduled for late 1993. The 
operational flight software and the ground control software are 
being developed in Ada. These software systems are currently in PDR 
phase. This paper discusses some of the Ada related observations 
that have been made to date. 

OMV Background. The OMV project is the result of a need to extend 
the capability of the Space Shuttle to meet an anticipated set of 
diverse requirements as they evolve for the Space Station and other 
orbiting space platforms. There is an existing Shuttle capability 
to place and retrieve satellites in low earth orbit. Servicing of 
platforms and vehicles at higher orbits becomes considerably more 
impractical or impossible. The OMV capability is responsive to this 
need and the various OMV configurations provide a flexibility over 
a wide range of mission requirements. 

The OMV is an unmanned vehicle that is deployed from the Shuttle 
and piloted from a ground station or commanded from the Space 
Station. The vehicle may be configured to accommodate differences 
in payload mass, mission length and mission duration. The OMV may 
be space based for an extended period between missions and refueled 
or serviced on orbit. Vehicle navigation is highly automated by 
means of the on board guidance and control software and the mission 
sequencing capability. The actual docking phase of rendezvous 
operations is accomplished by a man-in-the-loop pilot that controls 
the vehicle through a ground based pilot interface. 

The ground station provides the pilot with mission critical data 
and vehicle control in real time via the NASCOM link. The on board 
radar information, position data and video image are displayed on 
the pilot station chromatics graphics terminal. All other 
information in the vehicle downlink is available to the pilot for 
analysis. This data is also made available by the ground control 
system in real time and historically for the various mission 
support and monitoring functions. The actual real time control of 
the vehicle is accomplished by the pilot with the custom hand 
controllers and switches the comprise the pilot station controls. 

Software . The two basic software categories for the OMV program 
are the Flight Software and the Ground Software. The major portion 
of flight software is that which resides in the OMV on board 
computer (OBC) and it will be primarily Ada (95%). The remainder 
of that which is called flight software is non Ada software and it 
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consists of the embedded OMV subsystem firmware and the control 
software intended to reside in the Space Station computer network. 

There are seven different software entities that comprise the 
ground portion of the OMV effort. The software for five of these 
areas will be largely comprised of that which has previously 
existed on other related programs or was developed in prototyping 
efforts early in the OMV program. These software systems provide 
the flight planning, pilot training and much of the test and 
integration capability. However, the actual Mission Operations 
Software that will reside in the Ground Control Console is to be 
developed entirely in Ada. Also, any additional test sets that are 
to be developed for use with the Electronics Ground Support 
Equipment (EGSE) will be written in Ada. 

Of significance is the fact that the most visible and critical 
portions of the OMV software are to be developed in Ada. These are 
the Operational Flight Software and the Mission Operations 
Software. These two subsystems complement each other as the air 
and ground portions of the real time OMV capability. The flight 
software provides the typical on board GNC and communications 
functions as well as mission sequencing, status monitoring and 
redundancy management. The flight machine is the CDC 444RR (1750A) 
with a dual CPU. 

The ground control software is to be hosted in the ground 
control console (GCC) which is comprised of two VAX 3600 machines 
that communicate with each other through a DMA link. In addition 
to pilot display and control, the ground software will provide all 
telemetry and command processing, data management, operations 
control and data analyst services. 

OMV Ada Evolution . The conclusion of a programming language 
evaluation study during the proposal phase of the OMV project 
stated that Ada was the most suitable high order language 
(independent of hardware and other considerations) when compared 
to FORTRAN or JOVIAL. However, at the time of the original study 
(1984), additional selection factors such as existing hardware 
availability, software development environment maturity and the 
existence of ''reusable" FORTRAN code for implementing OMV 
algorithms were enough to tilt the scale in favor of a FORTRAN 
implementation for both the flight and ground systems. The existing 
FORTRAN implementations of closely related algorithms and test 
systems represented a considerable amount of cost savings in the 
overall developed system. 

Nevertheless, by joint agreement at the beginning of the 
contract, the suitability of Ada to the OMV project was to be 
reviewed. The continuing evaluation strengthened the original 
conclusion that Ada best met the language requirements for both 
ground and flight software on OMV. Then in an OMV language trade 
study released in March 1987, a revised conclusion stated that Ada 
was not only the best choice, but that no other language offered 
a defensible alternative for a development effort whose anticipated 
useful life extends beyond the end of this century. The maturity 
of the available support had progressed to a very credible stage. 
The availability of Ada experience and Ada training also looked 
attractive. With emphasis on the fact that Ada was the language of 
choice for development efforts of significant expected life span, 
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the decision was made to implement the major development efforts 
of the OMV project in Ada. This meant that the Operational Flight 
Software and the Mission Operations Software were targeted as Ada 
development efforts. 

Development Teams . The flight and ground software development 
efforts are two distinct segments of the overall effort. It is 
proper to describe them in different terms since they are separated 
by geography as well as experience base. The flight team is largely 
composed of personnel with extensive experience in real time flight 
systems. The actual language experience is mostly assembly language 
with a significant amount of non Ada high order language 
experience. Before the OMV project, there was virtually no prior 
Ada experience. 

The ground team background contains noticeably more application 
experience as opposed to real time development. The experience in 
high order language is much more prevalent than assembly as well. 
Most of the ground team had been involved with at least one 
previous Ada development effort, although the software systems 
produced were applications, software tools and environments. 

All of development team members have been involved in extensive 
Ada training. The types and amount varied considerably. There has 
been a considerable amount of accredited course work as well as 
various types of seminar involvement, in house training and hands 
on experience. 

Significant Implementat ion Factors. There are several factors that 
are a part of the OMV program by design that are noted at this 
point since these factors have a significant influence on Ada 
experiences thus far. Observations concerning the Ada experiences 
are made with these factors in mind. 

1750A Flight Machine Architecture. The originally intended Litton 
4516 target machine selection virtually eliminated Ada from 
consideration due to lack of availability of an Ada tool set. At 
the time of the post award language study, there existed at least 
four validated compilers for the 1750A and three others were to be 
validated shortly. 

VAX/VMS Ada Development Environment. The VMS Ada environment is 
the system of choice as the development host for both the flight 
and ground software efforts. It is generally agreed that VMS is 
one of the most mature environments available for Ada development. 

TLD Toolset. Of those systems available, the VAX/VMS hosted version 
of the TLD cross compiler and toolset was chosen for the flight 
software development effort. The factors in the decision involved 
the existence of the TLD Interpretive Computer Simulation for the 
1750A architecture, the proximity of the TLD (Terry L. Dunbar) 
Corporation to the development effort and the reasonable cost. 

Prototyping/Benchmarking Exercise. The decision to acquire the TLD 
toolset provided both a motivation and opportunity to perform a 
comprehensive set of prototype/benchmark tests. These tests were 
to evaluate the efficiency of the TLD toolset from an operational 
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point of view and to evaluate the efficiency of the code generated 
by the compiler for each language construct. Also, the benchmarks 
were used to evaluate the TLD 1750A simulator and run time kernels. 
The results from this effort were captured in the Software 
Standards and Procedures Document for the OMV project. 

Prototype Conclusions . The overall impression of the TLD compiler 
is that it is very efficient and reliable. The compiler is 
intelligent in optimizing source code into efficient object code. 
There are problems and needed enhancements, but no show stoppers 
and the support from the vendor has been extremely responsive. The 
development environment is reasonable for developing software for 
a generic 1750A architecture. There will be enhancements required 
in order to emulate unique characteristics of the actual target 
machine. Basically, these enhancements are in the areas of 
simulating the timing and memory conflict associated with a dual 
CPU, more flexibility with regard to interrupts, a more 
representative I/O system and provisions for input to the 1750A 
simulation from an outside program. 

The implementation of several Ada constructs were judged as 
inappropriate for use in the flight system. Generally the 
associated expense of such structures was cited as the offending 
characteristic. A detailed list of these recommendations are 
available, however the more significant constructs to be avoided 
appear to be the tasking, variant record, private formal parameters 
in generics and access types. 

In general, any constructs that utilize dynamic memory 
allocation are not regarded as desirable in the flight system 
software. Reasons for this go beyond the concern in terms of memory 
and CPU expense. Of significance is that it is desirable for 
program execution to be deterministic for verification purposes. 
It is also desirable for memory to not be dynamically allocated so 
that everything in memory can be in a known location for telemetry 
fetching purposes and to accommodate on orbit patching. 

Observations to Date . The VAX/VMS development environment for both 
the flight and ground software systems is performing very 
satisfactorily. The ground team uses as a basis for comparison 
their prior development experience in a number of environments 
including the Alliant, SUN and various PC hosted environments. The 
compiler and linker are very efficient and reliable in terms of 
user interface as well as the generated code. The symbolic debugger 
is very mature providing an extremely useful run time environment. 
The CMS provides a flexible library system that tracks the various 
modules and their change history, enforces user control of modules 
and provides group and class operations. 

The eventual porting of software to the respective target 
machine is not expected to be an issue. In the case of the flight 
effort, the executable image will simply move from the TLD 
simulated environment to the target machine. The initial 
impressions of the simulator have been that it provides an accurate 
rendering of a generic 1750A target computer. Tailoring of the 
simulator to more closely represent the actual flight machine is 
expected to have been completed well in advance of the test and 
integration phase. The relatively small percentage of flight 
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software that is expected to be implemented in assembly language 
may be integrated within the simulator environment. 

The ground software migration will be from an initial 
development environment on the VAX 780 to an environment on one of 
the VAX 3600 series computers. This move will be conducted when the 
hardware is available in a timeframe well before the test and 
integration phase. The experience of the ground team with porting 
Ada source code between various vendors and models of hardware 
indicates that this should be a relatively painless procedure 
regardless of the development phase in which it takes place. The 
ground control software is to be implemented entirely in Ada. The 
only exception is the Job Control Language file that actually boots 

the system. . 

The generally accepted view that the integration and test phase 
of an Ada development effort may be significantly reduced in 
comparison with the integration phase of other languages is 
supported by the prior Ada experience of the ground software team. 
The observations to date indicate that even with the very large 
complex systems, source code that compiles cleanly will run 
comparatively well the first time that it is integrated. The 
problems associated with inconsistencies in definition and with 
unexpected side effects are greatly minimized. The mature ACS will 
eliminate problems associated with incompatible object versions and 
compilations in general are simplified by the Ada packaging 
concepts . 

observations on Constructs . The largest single factor in 
determining the desirability of an Ada construct for a particular 
application appears to be the maturity of the compiler and the 
associated Ada environment. Currently, the second leading factor 
is the set of constraints with the target system although the 
importance of this may diminish as the Ada language tools continue 
to mature and the hosting hardware improves. These trends would 
tend to reduce the number and magnitude of target host constraints . 
Finally, an increasingly significant factor is the experience and 
training of the developers. As the tools and hardware improve, the 
familiarity of the developers with the language becomes the 
significant factor in determining the degree to which the Ada 
capability is fully exploited. 

For purposes of observation, consider that there are three basic 
levels or categories that describe the usage of Ada constructs on 
a particular development effort. These are: 1) Constructs that are 
avoided - a diminishing yet stubborn group 2) Constructs that are 
applauded - those that are used universally throughout the effort 
3) Constructs that are Contested - those for which no universal 
opinion exists. The members of these categories for the OHV project 
are determined officially and otherwise by the factors described 
in the previous paragraph. A discussion of representative members 
of these categories follows. The list is not exhaustive because, 
among other reasons, membership sets continue to be dynamic. 

In the category of Constructs that are Avoided, Tasking is the 
most notable member. For the OMV, project the reasons are numerous 
and typical . There is a considerable amount of expense in terms of 
memory and CPU with all implementations of tasking. For the flight 
software, there is a desire to avoid all dynamic memory constructs 
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and those that would prohibit a deterministic execution. At the 
noise level, there is distaste for the fact that the 
implementations of tasking do not resemble virtual tasks in many 
respects . 

Many constructs are applauded and for the reasons that were 
intended by the language design. Most notable are the packaging 
and information hiding constructs. Also the Ada exception handling 
approach offers a very clean and efficient approach to anomalous 
conditions. The concept of generic code is often applauded and 
cited as having great potential in the reusability arena; however, 
in the OMV effort and from experience, it would appear that there 
will not be an overwhelming amount of generic code in the final 
product . 

Many constructs are contested for reasons ranging from 
prohibitive circumstances to preference. For example, variant 
records are prohibited in the flight code because the TLD compiler 
generates a tremendous amount of control code. However, in the 
ground control software, there are a number of message passing 
applications that are greatly simplified with the use of this 
construct. The Separate construct instruction to the compiler has 
experienced difficulty in the early VAX/VMS implementations as well 
as the TLD compiler. This may have influenced decisions to 
eliminate large employment of this construct although temporary 
usage of it during various development stages is quite common for 
convenience reasons. Mandates concerning uniform usage of context 
clauses receive mixed reviews from the developers. The trade off 
is in the area of readability versus self documentation. The 
relative merits of many other constructs are weighed in terms of 
utility and readability versus perceived or actual expense. These 
types of constructs include Arrays with initial values, IF 
statements with compound conditions and Private types as formal 
parameters in generics. 

Overall Observations . The overall impressions with the Ada language 
are extremely good. This is not unexpected considering that the 
language of choice for the OMV project apart from non language 
constraints has been Ada since the proposal phase of the program. 
Experience since the program start continues to reinforce this 
position. Some of the observations follow although this is not to 
be considered an exhaustive list. 

Prototyping. The prototyping/benchmarking exercise that was 
conducted shortly after the Ada implementation decisions were made 
produced a number of significant benefits. In addition to 
identifying the constraints that existed for an Ada implementation, 
the exercise provided an extremely good hands on learning 
experience. A similar exercise should be considered in the early 
stages of any Ada development task and especially where performance 
characteristics of Ada for the particular target are unfamiliar. 

Maintainability. The enhanced maintainability characteristic of 
Ada is generally recognized. In addition, observations of the team 
members from previous efforts as well as the OMV effort thus far 
substantiate the opinion that? the code is inherently very readable. 
The strong typing and information hiding characteristics of the 
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language minimize opportunities for breaking existing software in 
any modification or update process. 

Automation. The opportunities for automation of project related 
activities are enormous. The structured, coherent and consistent 
nature of the language are of course intended to support a language 
oriented tool set. Of particular note in the OMV effort has been 
the ' favorable results achieved with the use of portions of the 
ADADL development tool set. The developers have utilized automated 
assistance such as cross reference aids, pretty printers and 
reguirements allocation trackers. The PDR documentation for the 
flight and ground software PDRs was generated almost entirely by 
the DOCGEN tool . The actual development environment of the average 
Ada Compilation System (ACS) possess the capability to automate 
compilations, provide class and version operations and generate 
change histories. The availability of state of the art development 
automation as well as commercially available software packages 
appears to be guaranteed with the Ada language. For instance, the 
OMV project is utilizing a commercial data base system (SYBASE) 
server for all ground software data base related activities as the 
result of an extensive trade analysis between a large number of 
potential candidates. The selected system is a fast, mature and 
reliable system that interfaces with Ada extremely well. 

A final observation concerning automation opportunities in the 
Ada environment concerns the capability for automatically generated 
graphical representations of structure and control flow from source 
code. Typically the Ada developers are very satisfied with Ada PDL 
as a very reasonable and utilitarian representation of overall 
structure and control flow. However, there exists at present and 
for the foreseeable future a very significant demand for graphical 
representations of the software for use in interface with 
management, systems engineering and the customer. 
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ORBITAL MANEUVERING VEHICLE (OMV) 
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OMV OPERATIONAL COMMUNICATIONS 
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OVERALL OMV SOFTWARE STRUCTURE 
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ORIGINAL PROPOSAL BID FORTRAN 
Known Tools & Experience 


£ 

CD 

£ 

o 

CO 


c 

D) 

'55 

a> 

Q 

O) 

c 

■ MM 

w 

■ ^M 

X 

LU 


a> 

co 

3 

a> 

cc 


<D 

CO 

3 

O 

CC 


T3 £ 

§ i 


■D 

0) 

"(D 

e^M 

O 

o 

CO 

CO 

< 

CO 

O) 

c 

> 

CD 

CO 

“co 

o 

o 


a> 

.Q 

■ MM 

T3 

£ 

O 


O 

o. 

a. 

3 

> CO 
Q a> 

£ s 

&S 5 

BJ 2 

3< 

a o 

w >, 

I- .tr 
co !r 
lu 5 
3 co 
O S 

LU 

CC 

< , 
CO 
< 


G) 

JQ 

JD 

‘co 


r < 


a> 

o 


© 

Q. 

X 

LU 

CO 

■o 

< 

c 

CO 

o 

• MM 

c 

O) 

CO 


a> 

o 

c 

CO 

c 

a> 


co 


.2 E 


0) 

h- 

a> 

c 

o 


CO 

.X 

o 

CO 

A 

>» 

CO 

CL 


CO 

■o 

2 < 

2 <= 

CO 0) 


-J g 
O | 

Z 5 

o o 
O 2 

111 n 

co .2* 


O 

cc 

CL 


CO 

■o 

< 


a> 

CO 

*: 

o 

CO 

co 

c 

o 


CO 

CO 


CO 

■o 

< 

£ 
■ MM 

LU 

CO 

o 

LU 


X .= O O 

co a> - g - 

iw <0 CO 

ra *r 


CO 

5 0) 

a. CO 

o «- 

_ CO 

£ a> 


$ 

a> 


O 

O 


W. Harless 
TRW 
14 of 22 


Remaining Software in FORTRAN or 'C' 



DEVELOPMENT TEAM BACKGROUND 
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All Development Team Candidates Have Participated in Ada 
Training 
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Ada Constructs Trade-off Analysis 


CONCLUSIONS FROM PROTOTYPING 


CO 


> 

£ 

DC 

3 

h- 

< 


CO 


O) 

n 

CO 

C 

o tr 
<g o 

CD X 


Q LU 

n 

§ i 

Q 

LU 

5 ■ 

LU 


a> 

DC 3- 

(5 co 

CO "O 

o O 

o o 

H O 


o 

H 

< 

o 

CL 

0. 

< 

LU 


< 

LU 

DC 

DC 

o 

U- 

m 

UJ 

> 

CO 

z 

LU 

Q. 

X 

LU 


0) 

> 

s 

o 

C3 

&- 

CO 

c 


CO 

o 


CO 

CO 

4> 

a 

o 


S3 CL 

» 2 

fl> 


a> 

T3 

o 

o 

jC 

o 

3 


O 

o 


c 

£ LU 

2 22 


m 


x: 

o 

O) 

c 


W 

fl) A 
« 
3 « 
O-Q 

a> 


JC w 

</) nr JC 
<0 “■ 0) 


0. 

O 

x: 

o 

3 


3 H ^ 


o 
o 

I- 

co 

-J C o 

CC2 
h co 
CO « • 

o 

o 

LU • 

2 

O 

CO 


(0 
O (0 

“ H 
c 


<D « 

£ c 

O E .. 

§s§ 

f- 


<o 


"O 

0> 

<-* 

<0 

k_ 

© 

c 

a> 

O 

0) 

T3 

O 

o 

<5 ® 
^ c 

»- 3 
O O 

O E 

CD < 

co 
C « 

coZ 

■ ■■> 

CD • 


CO 

o 

a> 

c 

<D co 

o? 

o $ 

— a 

2 «= 

a> .2 

% 2 

|8 

CD CD 

m <3 
CO m 

0-S 

CO o 

E j2 

2 O | 


CO 


CO 


CO m 

a> 1 
Q-c 

HE 

CD 2 

II 

■=«£ 

is 

tr co 
O is 

<2 « 

og 


W. Harless 
TRW 
18 of 22 


SOME CONSTRUCTS IMPRACTICAL FOR FLIGHT REQUIREMENTS 
Dynamic Memory Constructs 

• TLM Fetching 

• Patching 

• Debug 
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INTEGRATION TIME SIGNIFICANTLY REDUCED 
- Compilable Code 2 correct code 



OBSERVATIONS TO DATE (Including prior Ada 
(Continued) 
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OVERALL OBSERVATIONS 
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One of many Ada Design tools 
Cross reference 
Pretty Print 

Document Generator (DocGen for Preliminary Design) 



OVERALL OBSERVATIONS (Continued) 
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LESSONS LEARNED: 

PROTOTYPING WITH ADA FOR THE SPACE STATION FREEDOM 

Kathy Rogers 
Leslie Ambrose 
The MITRE Corporation 
1 120 NASA Road 1 
Houston, Texas 77058 


ABSTRACT 

Developing prototype software in Ada leads to some conclusions about the language as well as the 
available methods and services. Results from this project address the use of the Ada language in a network 
environment intended to emulate that which will exist onboard the Space Station Freedom. Conclusions are 
drawn concerning the strengths and weaknesses of Ada for prototyping projects. 


PURPOSE OF THIS PAPER 

This paper documents the lessons learned as a result of building the Human-Computer Interaction Lab 
(HCIL) Ada Executive (HAE). The HAE is a specialized program which obtains data from a testbed 
network built to evaluate candidate services and resources that will be required of the Data Management 
System (DMS) for the Space Station Freedom Program (SSFP). The HAE supplies data to the HCIL 
Multi-Purpose Application Console (MPAC) prototype which evaluates the presentation of data and 
information. 

This paper is an attempt to glean from the HAE that information which may have applicability to an 
audience larger than that which was directly involved in the effort The experience of prototyping a 
relatively small system in Ada, in a network environment provided insight into challenges that might be 
expected when developing larger software systems, especially those systems that might exist on the Space 
Station Freedom. To that end, many details of the project’s history have been omitted and other aspects 
have been elaborated in a manner which is not in proportion to the actual effort 

This paper will focus on the process of developing the Ada production and test software that was used 
as part of the larger testbed effort to evaluate various data services and resources 1 . After a brief history of 
the prototype, this paper addresses the Ada and software engineering issues confronted by the prototype. 


BACKGROUND ON THE HCIL MPAC PROTOTYPE 

The electronic component of a workstation onboard Space Station Freedom is an MPAC. The effective 
use of this instrument will be important to crew productivity. As such, the National Aeronautics and Space 
Administration (NASA) wished to investigate the human factors issues associated with the presentation of 
infoimation on the MPAC. The DMS testbed at the Johnson Space Center (JSC) provided the necessary 
resources and data for MPAC analysis as part of the System (QMS) Integration effort. 


1 This project was done as part of contract NAS9- 18057, project 3100K. This paper is a partial summary of a 
larger report, “Lessons Learned: Object Oriented Methodologies, Ada, The Data Management System Testbed, and 
Prototyping”, JSC 23903, September 1989. 
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The OMS Integration effort is an ongoing series of prototype demonstrations, focussing on establishing 
interoperability between Space Station Freedom system simulations. It runs in the environment of the DMS 
Testbed, which is based upon an Apollo token ring network with Ethernet The configuration of the DMS 
Testbed for OMS Integration Demonstration 3A is shown in Figure 1. System simulations are hosted on 



Figure 1. OMS Integration Demonstration 3 A Participants 


the various nodes of this network. It was in this environment that the HCIL MPAC Prototype was to 
become a player, focussing on the data from the Guidance, Navigation, and Control (GN&C) node. The 
OMS Integration effort represented a good source of realistic data which could serve as the basis for 
analysis of candidate MPAC displays. 

A User Interface Management System (UIMS) is a piece of software which facilitates the 
development of consistent, effective user interfaces by providing development tools and a runtime 
environment to present the products of those tools. The BLOX® UIMS is controlled by user-defined state 
tables, which respond to interface commands by invoking user-defined programs. The combination of the 
commercial BLOX package, its external tables, and the display process programming, will be referred to 
collectively as BLOX. 

The need for the HAE arose due to the fact that the services and resources provided by the DMS 
Testbed did not match the needs of the BLOX UIMS. The HAE acts as a middleman, requesting data from 
the DMS Testbed network (in the proper format) and making it available in the proper format for BLOX. 
Figure 2 shows the relationship of the HAE software to the other HCIL MPAC Prototype components. 


® BLOX is a product of Template. 
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Had the Testbed services provided a more tailorable, extensible interface, there would have been no need to 
develop additional software. 



OMS 

TESTBED 

NETWORK 


To GN&C and 
other nodes 


Figure 2. HCTL MPAC Prototype Components 


HAE OVERVIEW 

The HAE is a relatively small piece of software, consisting of approximately 2000 Ada statements of 
unique source code 1 . It was developed under VMS® 4.7 on a VAX® cluster, which included a VAX 785 
and 8810. It was run on a Micro VAX®. The prototype configuration is depicted in Figure 3. Its 
executable code occupies 95K bytes and the additional object file which is linked into the BLOX program 
occupies 53K. No code metrics were kept during this effort, but an informal evaluation of libraries upon 
completion revealed that approximately 6500 lines of test code had been written. 

The HAE provides services to BLOX through a series of procedure calls. The interface was designed 
to accommodate communication between two very different languages, C and Ada, and is simple and 
straightforward as a result. The HAE services include 1) periodically gathering data values from the 
network, 2) returning those values to the user, 3) returning the type and units of available data, and 4) 
stopping the HAE. 

The HAE performed satisfactorily in its intended demonstration. It handled data updates from the 
network at the rate of 0.3 messages per second, where each message contained up to 48 data elements. The 
BLOX system takes several seconds to update the screen. The HAE provides data values in approximately 
1/4 second per query. 1 This is fast enough for the present application, since it is not a "hard" real time 
system. The end user has expressed satisfaction with the system. 


1 Reused software is counted only once, and software from outside sources is not counted at all. The statistics on 
Ada statements were generated by counting semicolons which occur outside of comments and parentheses. The 
overall statement statistics can be found in Appendix A. 

® MieroVAX, VAX and VMS are registered trademarks of Digital Equipment Corporation. 

1 This average is based upon tests using a test harness which accesses and prints system time immediately before and 
after issuing a call to the HAE. 
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Figure 3. HCIL MPAC Prototype Software Architecture 

The HAE has not been fully exercised, but so far has proven to be robust (i.e., it has not failed to 
perform its intended functions). It was designed to support queries to multiple systems, but this capability 
has not been exercised. The overall design of the HAE was found to be sound and resulted in a functional 
product. 


ADA IMPLEMENTATION LESSONS 

One of the goals of this task was to gain some firsthand impressions of the Ada language. Since the use 
of Ada has been mandated for the Space Station Freedom Program, the Spacecraft Software Division (SSD) 
at JSC was interested in exploring software engineering and Ada. The observations of the language as an 
implementation tool are presented in this paper 2 . 

The use of Ada for this project was quite successful. In many ways, the properties of the language, 
particularly information hiding, contributed to the success of the prototype. The problems encountered do 
not appear to impinge upon the usefulness of Ada as a software engineering tool or as a prototyping 
language. They do have implications, however, for required tools, approaches, and support systems. 

The remaining discussion on Ada implementation issues is organized into two categories: successful 
aspects of our use of Ada, and areas which require attention in order to achieve positive results. 

Successes 

Ada proved to be a workable language whose use offered some specific benefits to this project. We had 
positive experience with Ada in the areas of information hiding, readability, language-to-language interface, 


2 Other issues such as object oriented methodologies, the Data Management System testbed, and prototype project 
management are described in the full report, JSC-23903. 
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and tasking. We also found that performance was not a problem in this system. Information hiding and 
readability were anticipated benefits of the language. The remainder, however, were areas where we were 
initially apprehensive about success. Instead, we found them to be straightforward. 

Ada’s information hiding capabilities facilitated independent development of components. The first step 
in the coding process was to formalize the design into Ada package specifications. The MITRE team did 
modify these specifications twice due to changes in types, but the consequences were minor and limited 
mainly to recompilation and linking. Eventually, a set of stub programs was created to allow unit testing. 
We possibly could have enjoyed even more of the benefits of this feature of Ada by building these stubs 
earlier in the project 

The use of modular specifications facilitated independent work, with each team member coding separate 
units. Eventually these were combined for system testing, which worked surprisingly well. No interface 
problems were encountered which could be attributed to the use of Ada; rather, Ada greatly facilitated this 
step. 

The only interface problem was due to the use of integer codes to return error conditions back to the 
BLOX program (e.g., 0=Successful, l=MSID_Not_Iri_MML). This resulted in tight coupling between 
several modules because the information about each value’s meaning had to be contained in each module 
involved. This was a memory burden for the programmer as well. In an all- Ada system, this would have 
been neatly solved by use of an enumerated type coupled with the use of exceptions and handlers. 

The Ada code for this project proved to be readable, at least from the perspective of the team members. 
We had one code review and several occasions where one member had to pick up the work of the other due 
to absence. Our observation was that, even with minimal use of comments, the structure and purpose of the 
code was accessible to the moderately informed reader. A strong reminder of this characteristic of Ada was 
provided when we had to make alterations to the screen definition code for BLOX, which was written in C. 
Minor changes proved to be a difficult undertaking. This comparison is somewhat suspect since neither 
team member is an expert C programmer, but both had experience with the language and the advantage of 
having reviewed the code with the author. 

When formal prologues were included in the code, programmers making modifications were inspired to 
record their changes. When there was no prologue, change comments were rarely added. Providing a 
prologue at the beginning of the coding phase and contributing information incrementally was much easier 
than recreating it upon completion of coding. Consequently, we recommend the use of prologues on all 
files. As only a minimal amount of information was required, the sample prologue in Figure 4 could be 
used as a basis. 

Other prologue information, which could be part of the abstract, should include the performance 
characteristics of the compilation unit (e.g., whether it was optimized to minimize the use of storage or 
minimize execution time), and the effects of the use of the object (e.g., side effects, exceptions raised, 
exceptions handled). 

Part of this project involved an interface between the C and Ada languages. The independent HAE 
process wrote to and read from VAX VMS mailboxes. Ada procedures to access these mailboxes were 
made available to the BLOX C program via the DEC-supplied pragma EXPORT. This process worked 
well, due to the hospitable environment provided by the VAX VMS operating system. 
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- Package Name: <Ada package name>, <ope rating system file name> 

- System Specification: 

- <hardware> miming coperating system> <version/revision> 

- Abstract: deference the design document section or page> 

- cdescription should include discussion of object > 

- cdescription of modifications should be added as needed> 

- Authors): 

- <name> <affiliation> 

- Modification History: 

- Created: cdate> 

- Modified: cdate(s)> 


Figure 4. Sample Ada Prologue 

One minor restriction was found: only base types could be used at the interface of procedures to be 
exported. Initially, we used restricted integer types which made sense from an Ada perspective, but which 
caused errors when used from C. As a consequence, we had to modify some package specifications and 
deal directly with DEC-supplied types for floating point numbers (i.e., gjloat or h Jloat instead of float). 
This obviously impinges on the customary benefits of Ada: we suspect that such loss at a language-to- 
language interface is inevitable. Where possible, such interfaces should be avoided in order to maximize the 
benefits of using Ada. 

Evaluation of tasking was not originally called out as an area of investigation within this project; 
however, the design appeared to be most easily addressed using tasks. Each of the top-level, concurrent 
objects could be a task, with its methods supplied by task entries. Overall, tasking worked well in spite of 
our concerns that it would add a level of technical difficulty. We were able to consider each unit 
independently, working from specifications. 

We shielded our task entries with procedure calls (Figure 5). Unshielded tasks can be aborted from 
anywhere within their scope, an undesirable situation for our purposes. The shielding offers the added 
benefit of reduced runtime overhead. If we were required to reduce the code size, the abort semantics could 
be removed from the task semantics since they could not be used. The shielding technique also allowed us 
to replace the task packages with non-tasking dummy versions. In these dummies the procedure calls, 
instead of calling task entries, merely supplied hard-coded values. This was helpful for testing and 
indicates that, had tasking proved to be a problem, we could have substituted a non-tasking version without 
affecting the remainder of the system. 

Much has been said on the performance weaknesses of Ada. Our requirements were not strenuous, but 
we had to provide adequate performance to update a display screen fast enough for a waiting human user. 
We did not experience any performance problems attributable to Ada. 

File I/O on the VAX was quite slow, but that is a characteristic of the system, not the language 
implementation. For example, one procedure call causes the HAE to open a file, read its contents and create 
some data structures. This is the slowest procedure call, taking approximately 2 seconds to execute. 
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package Master_Measurement JList is 

procedure Supply_MSlD_Spec(...); 
end Master_Measurement_List; 


package body Master_Measurement_List is 

task The_MML_Process is 

entry Supply_MSID_Spec(...); 

end The_MML_Process; 

procedure Supply_MSID_Spec(...) is 
begin 

The_MML_Process.Supply_MSID_Spec(. 
end Supply_MSID_Spec; 

task body The_MML_Process is 

select 

accept Supply_MSID_Spec(...) 
do ... 

end Supply_MSID_Spec; 
or 

end select; 

end The_MML_Process; 

begin 

null; 

end Master_Measurement_List; 


Figure 5. Shielding Task Entries 

Areas to Watch 

Support is critical to effective use of any new tool. Although both members of the development team 
had experience in Ada development, neither was expert in the VMS environment There were a number of 
times when having an expert in the combination of Ada and VMS would have greatly facilitated the 
development process. The usefulness to a project of one system expert should not be under rated. 
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Testing progressed slowly and a large amount of test code was generated, more than three times as 
many statements as the product. The features of Ada which make it good for large, complex projects — in 
particular, strong typing — slowed down the testing process. Test scaffolding took longer to create than 
was anticipated based on experience with other languages. “Quick and dirty” is only relatively possible 
with Ada. Test programs must be carefully constructed: packages must be instantiated to allow debugging 
print statements, types must be matched, values of records must be fully redefined with each change. This 
rigor is arguably a virtue, since better testing programs might lead to a stronger product. However, the 
additional time was not built into the schedule of this task. In a prototype, whose life span is expected to be 
short, it is not clear whether this rigor is a net benefit. It is therefore important to manage the whole 
process, planning in extra time and taking a more formal approach to testing than might otherwise be done. 
In a larger project, success or failure could hinge on the creation and management of test structures. 

A repository of existing Ada code was available for reuse on our host machine. The NASA Ada 
Software Repository provided for the acquisition and analysis of Ada software (developed by, for, and 
outside of NASA) for possible distribution and reuse within NASA. Ultimately the software within the 
NASA Ada Software Repository will be used to seed the reuse libraries of various NASA software 
development efforts. Tools to qualify software items into the library, classify them according to their 
projected uses, and retrieve them from the library based on the users' specifications are in the analysis and 
evaluation stages. At the current time, the software carries no warranties because of the disparate sources of 
software and the diversity of conditions under which the software may be used. 

Although we encountered some difficulty, we did reuse two programs from the repository, after making 
the minor corrections required to compile them. These programs accounted for approximately 1% of the 
final product Even with the searching, analyzing, correcting, and testing, this process was much faster 
than developing the code. Providing libraries of reusable code is complex, but judging even by our limited 
use of such services, it is a potentially powerful aid to progr amming 

Configuration management is another difficult task in software engineering. We used the VAX’s file 
numbering scheme coupled with named directories and paper records. Better configuration management 
tools and practices would have been useful during this project, although we experienced no real disasters. 

No code was irretrievably lost, but time was occasionally taken up in finding it In short, we were 
vulnerable to machine failure or human error at many points in the project Only the stability and small size 
of the design team, the relatively short development time, and a healthy dose of luck kept us from a major 
loss of work. 

We advocate almost complete avoidance of the USE clause in Ada. This clause, which allows the 
programmer to reference parts of library packages without supplying their full names, leads to confusion for 
anyone attempting to read the code. Our recommendation is based upon the experience of tracing references 
to find the source of a certain type or procedure — a frustrating exercise. The DMS Services supplied on the 
testbed include the Data Acquisition and Distribution Service (DADS) and the Network Operating System 
(NOS). These services, used by testbed participants to effect data transfer, are supplied via a series of 
procedures which may be incorporated into a node’s code. The sample programs demonstrating the use of 
these procedures employ the USE clause to the whole compilation unit and supply only local names for the 
type and procedure names. Since ten or more libraries are imported by these programs, the programmer is 
left with the options of examining the specifications of each to find the source of each type and procedure, 
or of including all the referenced libraries in his/her own code. 
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There are very few, if any, good uses for the USE clause. Currently available pretty printers do not 
provide the capability to fully qualify references, to our knowledge. Even if that capability became 
available, it may still be inappropriate to use the USE clause because it can increase compile time for 
resolving overloaded subprograms. Not only must a compiler find an appropriate reference (in terms of 
subprogram name, number of arguments, type of arguments, etc.), it must assure that there is no other 
subprogram that could possibly fit the profile. Therefore, it has to look at everything that has been 
referenced by a USE clause. 

Fully qualified names are generally straightforward and readable for procedures and data types. 
However, they are less convenient for infix operators. In an application which requires an overloaded infix 
operator (or whenever package names become cumbersome), the RENAMES construct is preferable to the 
USE. For example, consider overloading the "+" operator for addition of two matrices. Direct referencing 
of the operator is clear but awkward: 

Result := Math_Routines."+”( Left, Right) 

The renames construct, however, allows a more natural format: 

— declarative part 

function "+"(L, R: Some_Type) return Some_Type renames Math_Routines."+"; 

-- sequence of statements 

Result := Left + Right; 

Additionally, only the "+" operation would be visible, eliminating the readability and compilation 
problems within the scope where the "+" is needed. To make other subprograms visible, other renames 
clauses would have to be used. 

In a tasking program, robustness of tasks becomes very desirable. User-defined exceptions whose 
handlers caused tasks to fail were difficult to diagnose and were removed from the final system. There was 
no situation encountered in this project where failing was preferable to continuing to run, although one can 
imagine a program such as a robot driver where the opposite might be true. 

The experience base of users familiar with both VMS and Ada is limited, and DEC’S Ada is not as 
mature as some of their other languages. We encountered a number of areas where we were unable to find 
other users who had exercised the capabilities we needed, particularly in the use of VAX system services. 
At least part of these troubles can be attributed to our lack of experience with VMS. The DEC 
documentation was a source of problems for two reasons: the necessary information was spread out over a 
number of manuals (five in one case 1 ); and the Ada documentation contained many inaccuracies. Needless 
to say, this slowed down our efforts. 

The VAX debugger changed the observed behavior of the system, particularly in matters related to 
timing. Code compiled with the debug option produced different results from that compiled without debug, 
even if run in the / nodebug mode. Fortran programmers report that this is a known characteristic of the 
debugger, so this does not appear to be an Ada-only problem. It should be noted that, even with this 


1 The problem was the use of mailboxes. The manuals were the following: VAX Ada Programmers Run-Time 
Reference Manual; VAX Ada Language Reference Manual; VAX VMS System Services; VAX VMS I/O User’s 
Reference Manual; Developing Ada Programs on VAX/VMS. 
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problem, the debugger was a useful tool However, the confusing results combined with our unwise faith 
in the tool slowed down the resolution of some problems. In this, and other im plementation pro blems , we 
found it helpful to use the technique of keeping a "lab book" describing die problem encountered, steps 
taken to isolate the problem, and the success or failure of each attempt This book fostered deliberate 
debugging and acted as a communication device during the absence of a team member. 

Some apparently inconsistent results were obtained. One particularly annoying problem was the failure 
of some code to “scale up”. It seemed nonsensical to claim that the mailbox reads and writes worked in a 
small program but not when included in the whole system, yet that was the observed behavior. A 
systematic set of tests finally revealed the culprit, as shown in Figures 6 and 7. Calls to the package 
VAX_Mailbox_Services, which invoked VAX system services, failed when done from a subprogram 
defined within the scope of the main procedure. The simple test program had its calls in line and therefore 
avoided this problem. We are unaware of any place where this is documented. 

In a process which uses tasks, direct calls to VMS general input/output system service routines $QIO 
and$QIOW from a single task result in blocking the whole process. DEC Ada tasking is implemented 
using a run-until-blocked method. According to the VMS documentation, the system does not recognize 
that the individual task is waiting and therefore does not allow any other task to run (Digital, February 
1985). In order to avoid this affect, the user is directed to employ the DEC-supplied package 
Tasking_Services which avoids this problem. An additional work-around is offered by the DEC-supplied 
pragma TIME SUCE. This allows the programmer to control the maximum amount of time given to any 
one task. 


SUMMARY 

This project resulted in a working prototype which met its objectives of being a participant in the 
OMS Integrated Demonstration and of providing a tool for examining data presentation issues. The HAE 
software itself is a functional piece of software which could be used to attach another node to the DMS 
Testbed, at least until the Testbed Services are upgraded in 1990. Any UIMS or other software which can 
call Ada procedures in a VAX VMS environment could make use of the HAE. 

In the process of creating one portion of the prototype, the HAE, lessons were learned on the 
techniques and tools used to create the software as well as about the process of prototyping itself. Ada is a 
useful language whose benefits were clearly recognized during this project Its information hiding and 
tasking were particularly helpful: the use of Ada specifications allowed independent development of 
packages, and the tasking model fit well into a design of independent functional units. Each portion could 
be considered in isolation. 

Some planning, however, is required to avoid potential trouble spots. The youth of the language 
means that the support systems, both human and machine, are not as mature as is desirable. The availability 
of good programming tools and of a repository of indexed and qualified reusable code would greatly speed 
project development Further, the aspects of Ada which are its strengths, such as compiler-enforced typing, 
mean that quick and dirty development is only relatively possible. This does not mean that it is not a good 
prototyping language, but the schedule impacts must be considered. A second prototype, implemented by 
the same team, would undoubtedly be much faster to develop than the first 
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“This program does not work. 


with Text_IO; 
with Staiiet; 

with VAX_Mailbox_Services_Without_Tasks; 

procedure User_Mailbox_Manager is 

package VMS renames VAX_Mailbox_Services_Without_Tasks; 

Receiving_Channel Starlet. Channel_Type; 

Sending_Channel : Starlet Channel_Type; 

procedure Stait_Mailbox( R_Channel : out StarietChannel_Type; 

S_Channel : out Starlet. Channel_Type ) is 
From_BLOX : VMS.HAE_or_BLOX := VMS.HAE; 

For_BLOX : VMS.HAE_or_BLOX := VMS.BLOX; 

Start_Status : VMS .HAE_Status := 0; - o.k. 

S_Mailbox_Status : VMS.Status_Value := VMS.Success; 

R_Mailbox_Status : VMS.Status_Value := VMS.Success; 

Sending_Channel : StarieLChannel_Type; -for Sending mailbox 

begin 

VMS.Create_Mailbox( For_BLOX, 

S_Mailbox_Status, 

S_Channel ); - for sending 
VMS.Create_Mailbox( From_BLOX, 

R_Mailbox_Status, 

R_Channel); - for receiving 

end Stait_Mailbox; 

begin 

Start_Mailbox(Receiving_Channel, Sending_Channel); 
end User_Mailbox_Manager; 


Figure 6. Indirect Call Which Fails 
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— This program works. 


with Text_IO; 
with Starlet; 

with VAX_Mailbox_Services_Without_Tasks; 

procedure User_Mailbox_Manager is 

package VMS renames VAX_Mailbox_Services_Without_Tasks; 

R_Channel : Starlet Channel_Type; 

S_Channel : Starlet. Channel_Type; 

From.BLOX : VMS.HAE_or_BLOX := VMS.HAE; 

For_BLOX : VMS.HAE_or_BLOX := VMS.BLOX; 

Start_Status : VMS.HAE_Status := 0; — o.k. 

S_Mailbox_Status : VMS.Status_Value := VMS. Success; 

R_Mailbox_Status : VMS.Status_Value := VMS. Success; 

Sending_Channel : StarietChannel_Type; —for Sending mailbox 

begin - procedure Start Mailboxes and Network 

VMS.Create_Mailbox( For_BLOX, 

S_Mailbox_Status, 

S_Channel ); -- for sending 

VMS.Create_Mailbox( From_BLOX, 

R_Mailbox_Status, 

R_Channel ); - for receiving 

end User_Mailbox_Manager, 


Figure 7. Direct Call Which Works 
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APPENDIX A 


STATISTICS ON MODULES AND ADA STATEMENTS 


During the process of writing the code, information was not captured about versions or number of lines 
written or tested. I nstead, after-the-fact analysis has been done on die rather ad hoc library structure which 
was in place upon the successful completion of the product We attempted to gamer some information 
about reuse of code from external sources, the creation of code that was reusable within the context of the 
product, and the amount of test code required to produce a working result 

The following assumptions were made in examining the libraries: 

• It is not feasible to determine reuse below the module level. 

• If a module has a unique name, it is counted as a unique piece of code, recognizing that 

much code was duplicated. 

• If two modules of the same name have different numbers of statements, they are 

considered to be two different modules. 

The modules were classified by purpose (product , discarded, or test) and by source (new, reused, or 
new used multiple times). For each category, the number of modules and Ada statements was determined. 
The following table contains the overall results: 


Statements Modules Statements/Module 


Total 

11802 

Product 

2212 

Test 

6581 

Discarded 

3009 

Reused 

228 

New 

11419 

New Multiple 

155 


188 

62 

33 

67 

118 

55 

37 

81 

4 

57 

179 

63 

5 

31 
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To examine just the product code for reuse, the following table was developed: 



Statements 

Modules 

Statements/Module 

Product 

2212 

33 

67 

Reused 

174 

2 

87 

New 

1929 

27 

71 

New Multiple 

109 

4 

27 


Some ratios of possible interest follow: 



Statements 

Modul 

Test /Product 

2.9 

3.5 

Reused Product /Total Product 

0.08 

0.06 

New Multiple / Total Product 

0.05 

0.12 

New Multiple+Reused / Total Product 

0.13 

0.18 


These ratios reveal that the amount of test code is roughly three times the size of the product Reused 
code from external sources accounted for about 7% of the code, while code employed multiple times was 
5% of product statements and 12% of modules. The combined multiple purpose code accounted for 13- 
18% of total product code. 
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ACRONYM LIST 


ACS 

Ada Compilation System 

ADS 

Ancillary Data Service 

ANSI 

American National Standards Institute 

DADS 

Data Acquisition and Distribution Service 

DEC 

Digital Equipment Coiporation 

DMS 

Data Management System 

GN&C 

Guidance, Navigation and Control 

HAE 

HCIL Ada Executive 

HCIL 

Human Computer Interaction Laboratory 

JSC 

Johnson Space Center 

MML 

Master Measurement List 

MPAC 

Multi Purpose Application Console 

MSID 

Measurement/Stimulus Identifier 

NASA 

National Aeronautics and Space Administration 

CMS 

Operations Management System 

SSE 

Software Support Environment 

SSD 

Spacecraft Software Division 

SSFP 

Space Station Freedom Program 

UIMS 

User Interface Management System 

UMM 

User Mailbox Manager 
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Exploration of user interface issues in the DMS 


How the Human Computer 
Interaction Lab (HCIL) MPAC Works 
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Statistics on the HCIL Ada Executive (HAE) 
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Ada Lessons - Successes 
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Ada Lessons - Potential Difficulties 
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Effective Use of Tools Requires Support 
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Testing Creation Takes Longer 
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Standards to Support Ada Development 
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Rationale for Restricting the Use Clause 
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To shorten extremely long names 


Renames Clause as an Alternative 


c 

o 

■ ■MB 

2 

o 

c 

X 

m mmm 

C 

• MB 

5 

o 

To 

o 


(0 

0 ) 

E 

CO 

c: 

£ 

o 

Q> 

<0 

3 


5 

i 


i 

i 

CO 


4> 


DD 

5 


C/3 

QJ 

# a 

*-3 

a 

o 

04 


I 


a 

s 


H- II 
3 

o 


a 

C/3 

<U 

0* 


£ 

0) 

i 

i 


5 

I 


C/3 

0/ 

# e 

*3 

a 

o 

Q 4 


I 


a 


C/3 

0/ 


a 

a 

o> 

u 

'oT 

o- 


I 


a/ 

S 

o 

C/3 

• • 

C4 


e 

o 

0> 

C 

.a 



V* 

0) 

s 

q> 

-Q 

■ 

■ 


0X) 

5 

+ 

0) 

nJ 

II 


a 

C/3 

0/ 

P 4 


0) 

a> 

E 

co 

c 

o> 

c 

o 


o 

E 

d> 

v. 

X 

0) 

c 

0) 


CO 

o 


0/ 


C/3 

0/ 

£ 

a 

a 

a/ 

s- 


o> 


03 

OX) 

a 

03 

a 

a. 


g 

i 


CO 

CM 


K. Rogers 
MITRE 
27 of 29 



DEC-Specific Problems 
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Conclusions on HCIL MPAC Prototype 
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- Testing requires adequate schedule allowances 
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SSE PROJECT OVERVIEW 
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= SSE Standard Interface 
= No Interface Across Line 
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VIRTUAL MACHINE SERVICE 
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The SSE Architectural Design must satisfy both long-term requirements for 
technical viability, and immediate, user-oriented needs. These two demands are 
often in conflict. 
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Make/Buy/Adapt Recommendation 
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SSE ARCHITECTURE AND DESIGN 

SSE Object Class Specification - Outline 
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• Extensive Reuse of Flight Code In Simulator, Trainer, EGSE, ETS 



Flight Computer Architecture 
























Allocation of Flight Software Elements to Processors 
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Allocation of Flight Software Elements to Processors (cont) 
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Control Algorithms Processing/Data Flow 
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- Interface To Peripherals 
* Desirable For Embedded Systems 
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Cyclic Operations 
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Preliminary Timing Data 
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Lessons Learned In Ada Prototyping 
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e) a generalized, hypothetical description... 
used in analyzing or explaining something 



Definitions Of Prototyping: 
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after the prototyping activity is complete 
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NASA Space Station Freedom Program Software Life-Cycle 
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Preferred Software Prototype Life-Cycle 

SPIRAL MODEL (Boehm, 1986) 


* 




cc 

c 

m 

m 

i 

> 


Preferred Software Production Life-Cycle 

b-Model (Birrell and Quid, 1985) 
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Emphasis on cost and length of maintenance 
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Mobile Servicing Centre (MSC) 



'-SS-078 



Software Goals Or Risks Addressed By The Prototype: 
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Prototype Metrics 



Record notes and lesons learned during entire life-cycle 
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Requirements Analysis & Definition Phase: 

Engineering Interdisciplinary Communication; 



CO 

CO 

CD 


< 

C/3 

< 

C/3 

O 

0 

E 

< 

C/3 

V 

03 

O 

o 

T3 

O 

£ c 

03 O 

2 1 


5 £ 

CO “ 
m 10 

£ -E 

CO O 
’d 0) 

a. S’ 

CL «= 
< CO 
O 

j2 - £ 

S| 

1 § 
5 ° 

m O 


c^. o 

CO jfi 

t5 “ 

CO CO 
its d 

■c c 

< £5 

2 8* 
g Q 

$ m 

? £ 

co E 

co 25 

0 O) 

■a .55 

C Q 

CO *5 

Q. .52, 

3 _Q 

2 O 
a co 

CO CO 

O E 

6 a 

o o 

O C/5 

oS c 

CO s= 

E g 
0 E 

to b 

to £2 

c CO 
CO ^ 

O t 


>» 

0 

CO 

k- 

0 

> 

c 

o 

o 


c^- 

CO 

o 

« 4— 

E 

< 

_CO 

Q 


O 

O 

o3 

E £ 

0 LU 
co 


£ 


CO 

E 

-o 2 

0 0 

co Q 
0 Q_ 

-a o 

c o 


r O 
TO ,2 

O t- 


P. Gacuk 
SPAR Aerospace 
20 of 62 


V-SS-081 



Preliminary Design Phase: 
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Preliminary / Detailed Design Phase: 
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■ Centralized Vs Decentralized Control Decision Left To The Designer 
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■ Hierarchical Layered Object Diagrams 
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* Composite Objects 

(Note: The arrows indicate direction of control.) 
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Hybrid Methodology Object Diagrams: 
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Old Approach of Mapping Ada Units to CSCs & CSUs 


SPAR 


Object Oriented 
Design World 


Ada Implementation 
World 
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Object B - CSC 
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“An element specified in the design of a Computer Software Component (CSC) 
that is separately testable ” [ DOD-STD-2167A ] 
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Proposed Approach of Mapping Ada Units 
to CSCs & CSUs 
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Detailed Design Phase: 

Multiple Views Of The Design Are Required: 
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Withing Diagram 
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Package A Package B Package C Package D does 

generates handles handles and not handle and 

exception X exception Y re-raises therefore 

exception Z propogates 

exception W 
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Implementation Phase: 

Ada Feature Usage Guidance: 
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Implementation Phase: 

Ada Feature Usage Guidance: 
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Implementation Phase: 

Avoiding Recompilations Guidance: 
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Configuration Management Problems: 
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Configuration Management Problems: 
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Results Of Initial Code Optimizations: 
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APPENDIX A - LIST OF ATTENDEES 





SECOND NASA Ada USERS SYMPOSIUM ATTENDEES 


ADAMS, NEIL BENDIX FIELD ENGINEERING CORP. 

AIKENS , STEPHEN D DEPT. OF DEFENSE 

ALANEN, JACK SOHAR, INC. 

AMBROSE, LESLIE THE MITRE CORP. 

ANDERSEN, BILL DEPT. OF DEFENSE 

ANDERSON, FRANCES STANFORD TELECOMMUNICATIONS, INC. 

ANDERSON, MARSHALL DEPT. OF DEFENSE 

ANDREOTTA, DONALD J NASA/HEADQUARTERS 

ANGIER, BRUCE INSTITUTE FOR DEFENSE ANALYSIS 

APPLEGET, PATRICIA WESTINGHOUSE ELECTRIC CORP. 

ARBOGAST, GORDON W.- DEFENSE COMMUNICATIONS AGENCY 

ARMSTRONG, MARY IIT RESEARCH INSTITUTE 

ARMSTRONG, ROSE MOUNTAINET , INC. 

ASHTON, ANNETTE NAVAL SURFACE WEAPONS CENTER 

ATKINS, EARL ELECTRONIC WARFARE ASSOCIATION 

AZUMA, KENNETH I FORD AEROSPACE CO. 

BACHMAN, SCOTT DEPT. OF DEFENSE 

BAILEY, KIRK COMPUTER SCIENCES CORP. 

BARBER, TOM COMPUTER SCIENCES CORP. 

BARDIN, BRYCE M HUGHES AIRCRAFT CO. 

BARKSDALE, JOE NASA/GSFC 

BARNES, DAVID UNISYS CORP. 

BARNES, FRANK LOCKHEED MISSILE & SPACE CO. 

BARRY, GLEN EBA, INC. 

BASSMAN, MITCHELL J COMPUTER SCIENCES CORP. 

BEARD, ROBERT M COMPUTER SCIENCES CORP. 

BECK, HANK JET PROPULSION LAB 

BENEDICT, ROBERT J BOOZ , ALLEN & HAMILTON, INC. 

BENITEZ, MEG DEPT. OF DEFENSE 

BERRENS, MIKE TELEDYNE BROWN ENGINEERING 

BEWTRA, MANJU CTA, INC. 

BLAND, SKIP A UNISYS CORP. 

BOND, PAUL SAIC 

BOOTH, ERIC COMPUTER SCIENCES CORP. 

BREDESON, MIMI SPACE TELESCOPE SCIENCE INSTITUTE 

BREDESON, RICHARD W OMITRON, INC. 

BRENNEMAN, DALE COMPUTER SCIENCES CORP. 

BRESLIN, MARK GENERAL ELECTRIC CORP. 

BRINKER, ELISABETH NASV<*SFC 

BROWN, HARROLD E NASA/MSFC 

BROWN, MARTY COMPUTER SCIENCES CORP. 

BROWN, NEIL F DEPT. OF DEFENSE 

BROWN, OTIS GRUMMAN 

BUCKLEY, JOE COMPUTER SCIENCES CORP. 

BUELL, JOHN COMPUTER SCIENCES CORP. 

BUNCH, ALEDA SOCIAL SECURITY ADMINISTRATION 

BURLEY, RICK NASA/GSFC 

BUSBY, MARY B IBM 

BUTLER, MADELINE J NASA/GSFC 

CAKE, SPENCER C HQ USAF/SCTT 

CARLISLE, CANDACE NASA/GSFC 

A-l 


SECOND NASA Ada USERS SYMPOSIUM ATTENDEES 


CARMODY, CORA 

CARPENTER, MARI BETH B 

CARRIO, MIGUEL 

CAS AS ANT A, RALPH . . . 

CASE, ROBERT 

CATO, WILLIAM 

CERNOSEK, GARY J 

CHANG, JOAN 

CHEDGEY , CHRIS 

CHU, MARTHA 

CHU, RICHARD 

CHUNG, ANDREW 

CHURCH, VIC 

CISNEY, LEE 

COHEN, HERBERT E 

COHEN, SARA 

COLEMAN, MONTE 

COLSTON, RAYNETT . . . 

COOLEY, JAMES 

COUCHOUD, CARL B 

COVER, DONNA 

CRAFTS , RALPH 

CRAINE, BOB 

CRAMBLITT, FRANK . . . 

CRAWFORD, STEW 

CREASY, PHIL 

CREEGAN, JIM 

CREPS, DICK 

CROKER, JOHN 

CUCE, ROBERT J 

CUESTA, ERNESTO 

CUTTS, ROY D 


PLANNING RESEARCH CORP. 

CARNEGIE MELLON UNIVERSITY 
TELEDYNE BROWN ENGINEERING 
COMPUTER SCIENCES CORP. 

DEPT. OF DEFENSE 
HQ USAF/SCTT 

MCDONNELL DOUGLAS SPACE SYSTEMS CO. 
COMPUTER SCIENCES CORP. 

SPAR AEROSPACE CO. 

COMPUTER SCIENCES CORP. 

FORD AEROSPACE CO. 

FAA TECHNICAL CENTER 
COMPUTER SCIENCES CORP. 

NASA/GSFC 

AMSAA 

GENERAL ELECTRIC CORP. 

DEPT. OF THE ARMY 
COMPUTER SCIENCES CORP. 

NASA/GSFC 

SOCIAL SECURITY ADMINISTRATION 
COMPUTER SCIENCES CORP. 

SS&T, INC. 

LOGICON, INC. 

IIT RESEARCH INSTITUTE 

MCDONNELL DOUGLAS ASTRONAUTICS CO. 
FORD AEROSPACE CO. 

UNISYS CORP. 

LISAN CORP. 

DEFENSE COMMUNICATIONS AGENCY 
COMPUTER SCIENCES CORP. 

DEPT. OF DEFENSE 


D ' AGOSTINO , JEFF . . . 

DAKU, WALTER 

DANGERFIELD , JOSEPH W 

DANIELL, WALTER E 

DAVIS , TIM 

DECKER, WILLIAM 

DEGRAFF, GEORGE 

DEMAIO, LOUIS 

DEMEO, JOSEPH R 

DEMILLO, RICH 

DERENZO, BILL 

DEVARAJ , SAVITHRI . . 

DEVLIN, MIKE 

DEWBRE, DOYLE 

DIGNAN, DAVID M 

DIKEL, DAVID 

DOUGLAS, FRANK J 

DUBIN, HENRY C 

DUNIHO , MICKEY 

DUREK, TOM 


OAO CORP. 

VITRO CORP. 

TELESOFT 

IBM 

NASA/GSFC 

COMPUTER SCIENCES CORP. 

GRUMMAN 

NASA/GSFC 

FEDERAL AVIATION AGENCY 
NATIONAL SCIENCE FOUNDATION 
TARTAN LABS 

COMPUTER SCIENCES CORP. 
CONCURRENT COMPUTER CO. 

DEPT. OF DEFENSE 
DEPT. OF DEFENSE 
FOCUSED ADA RESEARCH 
SOFTRAN , INC . 

U.S. ARMY OFFICE OF TEST & EVAL. 

DEPT. OF DEFENSE 

TRW 


AGEN 


A-2 



SECOND NASA Ada USERS SYMPOSIUM ATTENDEES 


DUTTINE, VALERIE NASA/GSFC 

EGLITIS , JOHN LOGICON, INC. 

ELLIOTT, DEAN F SWALES & ASSOCIATES INC. 

ELLIS , WALTER IBM 

EMEIGH, MICHAEL LOGICON, INC. 

EMERSON, CURTIS NASA/GSFC 

EMERY, RICHARD VITRO CORP. 

ERB, DONA M THE MITRE CORP. 

ESHLEMAN, LAURA DEPT. OF DEFENSE 

ESKER, LINDA COMPUTER SCIENCES CORP. 

EUSTICE, ANN IIT RESEARCH INSTITUTE 

FAFF, TIM IIT RESEARCH INSTITUTE 

FEERRAR, WALLACE THE MITRE CORP. 

FERNANDEZ, AL COMPUTER SCIENCES CORP. 

FINK, MARY LOUISE A EPA 

FISHER, TOM BOOZ, ALLEN & HAMILTON, INC. 

FISHKIND, STAN NASA/ HEADQUARTERS 

FORSYTHE, RON NASA/WALLOPS FLIGHT FACILITY 

FOURROUX, KATHY TELEDYNE BROWN ENGINEERING 

FOUSER, THOMAS J JET PROPULSION LAB 

FOX, EILEEN M IDE 

FRIEND, GREGG COMPUTER SCIENCES CORP. 

GACUK, PETER SPAR AEROSPACE CO. 

GAFFKE , WILLIAM E PROJECT ENGINEERING, INC. 

GALLAGHER, BARBARA DEPT. OF DEFENSE 

GARCIA, ENRIQUE A JET PROPULSION LAB 

GARY, ALAN V TELEDYNE BROWN ENGINEERING 

GIESER, JIM VITRO CORP. 

GILL, CHARLES W COMPUTER SCIENCES CORP. 

GILLILAND, DENISE STANFORD TELECOMMUNICATIONS, INC. 

GILYEAT, COLIN ADVANCED TECHNOLOGY, INC. 

GIRAGOSIAN , PAUL ..THE MITRE CORP. 

GLASS, JEFF PROJECT ENGINEERING, INC. 

GLIES , MARK TELESOFT 

GODFREY, SALLY NASA/GSFC 

GOUW, ROBERT TRW 

GRAHAM, MARCELLUS NASA/MS FC 

GRAYBEAL, KYLE FEDERAL AVIATION AGENCY 

GREEN, DAVID COMPUTER SCIENCES CORP. 

GRIMALDI, STEVE BOOZ, ALLEN & HAMILTON, INC. 

GRONDALSKI, JEAN COMPUTER SCIENCES CORP. 

GRONECK, MIKE IBM 

GUENTERBERG, SHARON PLANNING RESEARCH CORP. 

HAIN, GERTRUD SABAS 

HAIN, KLAUS SABAS 

HALL, DANA SYSTEMS ENGINEERING AND SECURITY, INC 

HALTERMAN, KAREN NASA/GSFC 

HAMILTON, JOHN R FEDERAL AVIATION AGENCY 

HAND, ROBERT GRUMMAN 
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HANG, BAILEY T 

HARLESS, WALTON N 

HARRIS, BERNARD 

HAYES , CAROL 

HEASTY, RICHARD 

HEFFERNAN, HENRY G 

HELLER, GERRY 

HENDRICK, ROBERT B 

HENRY-NICKENS , STEPHANIE 
HERBOLSHEIMER , CHARLES 

HEYL, NORMAN F. . . . 

HIGGINS, HERMAN 

HILL, MIKE 

HILL, VICKI 

HIOTT, JIM 

HOLLADAY, WENDY T 

HOLLOWAY , MI CHAE L 

HOOTEN, MONICA 

HOUSTON, SUSAN 

HSU, JAMES 

HUDSON, WENDY 

HUTCHISON, GREG 


BALLISTIC RESEARCH LAB 
TRW 

NASA/GSFC 
UNISYS CORP. 

COMPUTER SCIENCES CORP. 

EDP NEWS SERVICES 
COMPUTER SCIENCES CORP. 
COMPUTER SCIENCES CORP. 
NASA/GSFC 

FEDERAL AVIATION AGENCY 

U.S. GENERAL ACCOUNTING OFFICE 

DEPT. OF DEFENSE 

MARTIN MARIETTA 

THE MITRE CORP. 

UNISYS CORP. 

NASA 

NASA/LARC 

FORD AEROSPACE CO. 

LIS AN CORP. 

INFORMATION DYNAMICS, INC. 
CONCURRENT COMPUTER CO. 

IBM 


IRELAND, THOMAS 


TEKTRONIX DEFENSE SYSTEMS 


JAHANGIRI, MAJID 

JENKINS-BNAFA, JOVITA 
JENKINS -HUNTER, CARA R 

JESSEN, WILLIAM 

JOHANNS ON, HANK 

JONES , CARL 

JONES, DAVID 


COMPUTER SCIENCES CORP. 

TRW 
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